AnsibleでWindows VMの構成

今日は先日作ったTerraformファイルで作成したAzure上のVMに対して、先日作成したAnsibleが動作するコンテナ上でAnsibleのPlaybookを書いて、VMを構成してました。 - ドメインコントローラーに昇格(新規フォレスト作成) - 必要に応じて再起動 - StandAloneRootCAに構成 - 必要に応じて再起動 - サブジェクトの別名を利用可能に構成 - Azure Stackに必要な証明書のためのCSRを作成 というところまで自動化しました。 変な所で色々とハマりましたが、結局目的のところまではできたので良かったです。VMをAzure上にイチから作成するところから含めて全部やり直しても構築時間で15分もかからない感じに収まってます。 他にもDocker for WindowsをつかってLinuxコンテナを利用したり、実PCのファイルシステムをマウントしたり、Dockerfileを使ってのビルドをローカルPCとGitHub連携したDockerHub上でおこなったりというところもずいぶん慣れました。 ansibleでPSCredentialを渡す所でxxxx_username, xxxxx_passwordという形で表記しておけばよいだけとマニュアル上で読んだのですが、実はxxxxの部分に使う文字列によって挙動が異なるように見える部分があってかなり時間を無駄に消費しました。一部スペルミスもあったりなどもあり。よくわからないエラーが出たときには一度クリーンなところまで戻ってから文字をコピペせずに慎重に打ち直そう…と思ったのでした。 ansibleからPoweShellDSCを利用する部分も理解しましたし、昨日、今日で結構Terrafrom + ansible(+ PowerShell DSC)の組み合わせには慣れた気がします。 というわけで今日の成果はこちら。 - [https://github.com/ebibibi/hccjp/tree/master/VMConfigure](https://github.com/ebibibi/hccjp/tree/master/VMConfigure) 明日と明後日は贅沢に丸々2日間Puppetのトレーニングです!楽しみです。

July 18, 2018 · 1 min · 胡田昌彦

ansibleが使えるコンテナイメージ

TerraformでWindowsVMを展開した後はansibleで構成を自動化しようと考え中です。 Windowsからの管理は現実的に無理みたいなので、仕方なくDocker for Windows上のLinuxコンテナで管理しようとかんがえています。 ansibleの公式イメージをpullすれば瞬殺だろうと思ったのですが以下のあたりはもう公式ではイメージメンテナンスされてません、ということだったのでそのままの利用を躊躇してしまいました。 - [ansible/ubuntu14.04-ansible - Docker Hub](https://hub.docker.com/r/ansible/ubuntu14.04-ansible/) - [ansible/centos7-ansible - Docker Hub](https://hub.docker.com/r/ansible/centos7-ansible/) で、勉強も兼ねて自分でDockerfileを書きました。(あまり根本的解決になっていない気もしますが) - [ubuntu_ansible/Dockerfile at master · ebibibi/ubuntu_ansible](https://github.com/ebibibi/ubuntu_ansible/blob/master/Dockerfile) Dockerfile作成中には「pip install –upgrade pip」というコマンドも入れていたのですがこちらはpipの9と10のバージョン違いによるトラブルが発生してしまいうまく行かず。結局pipのアップグレードはやらないことにしました(逃げ)。 このあたりは下記ブログに解説されていました。 - [pip install --upgrade pip (10.0.0) 後の奇妙な挙動について - 雑記](http://icchy.hatenablog.jp/entry/2018/04/17/064443) 助かりました。ありがとうございます。 というわけで、Dockerイメージも準備できました。 - [ebibibi/ubuntu_ansible - Docker Hub](https://hub.docker.com/r/ebibibi/ubuntu_ansible/) 次は、このコンテナを利用して、Azure上に展開したWindowsVMを自動構成する予定です。明日時間取れる予定…! 業務時間にこうやって自分がやりたい領域のことを勉強しながら作業できるのは本当にありがたいです。(注意:遊んでいるわけではありません。仕事です。)

July 17, 2018 · 1 min · 胡田昌彦

(主にインフラ系エンジニアから見た)コーディングやスクリプティングに関しての流れ

主にインフラエンジニアからみて、過去から現在までの流れ…のようなものを私が見えている範囲で記載してみました。昨今はクラウド化の流れと相まって非常に高度な自動化やインフラのコード化まで実現可能となっており例えば「スクリプトも書いたことありません」という人に対してどの領域から飛び込んでもらうのが効率的か…をちょっと悩んでいます。 もうコーディングレスでLogic Appとかそういうところに飛び込んでもらった方がはやいのかもしれないし、仮想基盤のことやWindows, Linuxの中の事はすっ飛ばしてTerraformとかコンテナとかそこに注力するところから入って必要が出たところで仮想マシン内部の処理に入ったほうがいいのかもしれません。でも、現実的にはシェルスクリプトとかPowerShellスクリプトの基礎とかは抑えておかないとだめかもしれないし・・・。結構悩ましい所です。 - 昔はバッチファイルやシェルスクリプトで繰り返し実施する作業の効率化がありました。 - その後Windows的にはWSHの時代があり、vbscriptでスクリプトを書いたひとも多かったと思います。 - その後Microsoft的にはコマンド毎にオプションが違ったりコマンドがなかったりすることを解決し、全て統一するものとしてPowerShellを生み出しました。(私の大好きな[Jeffery Snover](https://twitter.com/jsnover)さんの仕事です。) - これでMicrosoft系はPowerShellで全てオブジェクト指向の管理となりました。(バックグラウンドにあるのは.net framework) - 一方UNIX系は当初からなんでもかんでもテキストであるという思想でした。 - MicrosoftはPowerShellを標準として様々な製品を開発しました。GUIではできないことでもPowerShellでなら操作できる。GUIで操作しても裏ではPowerShellコマンドが自動生成されてそれが実行されている…というものも多くありました。(結果、仕方がなくPowerShellを使うようになった方も多いと思います。) - Microsoftはクラウドサービスにもその流れを取り入れました。PowerShellにてクラウドサービスの管理も行うことになりました。 - Chef, Puppetなどに代表されるような冪等性を備えた仕組みが登場してきました。(Infrastructure as code, Configuration as code) 何度実行しても「記載した望むべき状態になる」ことを特徴とします。 - これ以前は「これを実行したらこうなる、やって見る前に状態を確認して、やってみて、やった結果を確認する」というような作業の流れを記述するようなイメージでした。 - MicrosoftもPowerShell DSCにて冪等性を持つフレームワークを提供しました。 - Microsoftのオープンソース指向が進む中でよりマルチプラットフォーム化を意識した取り組みがなされるようになっていきます。 - PowerShellの継続開発が打ち切られ、PowerShellCoreに舵がきられます。PowerShellCoreはWindowsだけではなく、Linux, Mac等でも動作するマルチプラットフォームなPowerShellです。(バックグラウンドにあるのは.net core) - AzureにもCloudShellの機能がつき、ポータル上でもコードで制御できるようになります。これまでのAzure PowerShellよりも先にAzure CLI(UNIX系の文化)の方が先に搭載されました。Azure管理はPowerShellよりもCLIの方が優先されるようになってきています。 - クラウドサービスも普及する中で、大規模な環境ではもう個別に1台づつターミナルで作業するなり、RDPではいってGUIで操作するなりすることが現実的に不可能な規模になりました。このような環境ではコードで全てを制御可能な環境にすることは必須条件となりました。 - WindowsもWindows Server Coreが出てGUIがなくなり、さらにNano Serverにてどんどん軽量化していきます。 - Windows Server 2016, 2019となると継続的に進化するモデルはGUIが利用できなくなりました。 - 更に軽量化を推し進める中で仮想マシンではなく、コンテナに大きくトレンドが傾きます。 - コンテナの標準であるDockerはDockerfileというコンテナをコードで定義できる機構を備えています。 - クラウドサービスも冪等性をもったテンプレートにて展開可能な構造となります。AzureであればARMテンプレート、AWSであればCloud formationなど。 - ARMテンプレート、Cloud formationによるInfrastructre as Codeと仮想マシンの内部を構成するChef, Puppet, AnsibleのようなConfiguration as Codeによって仮想マシンベースの環境構築の完全自動化が可能となりました。 - ARMテンプレート、Cloud formationによるInfrastructre as CodeとDockerによるコンテナコントロールで完全自動化が可能となりました。 - 複数のコンテナプラットフォーム自体のコントロールという観点ではKubernetesが標準化してきています。 - AWSLambda, Azure Fuctionsのようなインフラ自体を意識せずアプリケーションロジックのみを記載すればそれでおしまいとなるようなサービスも出てきました。ここではInfrastructure as CodeやConfiguration as Codeすら必要ない世界があります。(これですべてまかなえるわけでもないですが) - DevOpsという流れもありますが、NoOpsに向かう流れの方が強そうに感じています。(私の感想) ※NoOpsはインフラ管理者がいらないという意味ではなく、極力インフラの面倒を見なくていいアーキテクチャを採用する、くらいの意味で捉えています。 ...

May 16, 2018 · 1 min · 胡田昌彦

このサイトの構造について(Web App for Containers)

このサイトはWordpressで構築されています。Azure上のサービスであるWeb App for ContainersにDocker Hub上の「wordpress」コンテナイメージを元にカスタマイズしたコンテナイメージを展開して動作させています。 Web App for Containersは本記事執筆時点の2018年3月現在では相対的に新しいサービスであり、これを使ったWordpressサイトの構築手法に関してはまだあまり情報がなかったため、備忘録も兼ねて構造を書き残しておきます。 全体像 下図がシステムの全体像です。 実行環境は全てAzure上にあり、1つのリソースグループに格納されています。 App Service on Linuxにより環境が定義され、その上でWeb App for Containerが可動しています。 Wordpressはコンテナ上で実行されています。 データベースとしてはAzure Database for MySQLを利用しています。 App Serviceドメインにて独自のドメイン(ebisuda.net)を取得、割当しており、DNSもAzure DNSを利用しています。 Web App for Containersに展開するコンテナイメージはDocker Hub上のカスタムイメージとして公開されています。 https://hub.docker.com/r/ebibibi/appservice-wordpress/ Web App for Containerにてこのコンテナイメージを利用するように設定を行っています。 Docker Hub上のこのコンテナイメージは、Git Hub上のレポジトリがソースに指定されています。 具体的には下記のレポジトリがソースです。 https://github.com/ebibibi/appservice-wordpress このレポジトリ内にDockerfileが記載されており、このDockerfileの記載内容に従ってコンテナイメージがビルドされます。 このGitHub上のレポジトリを手元のPCにクローンしVSCodeにて編集している状況です。 コンテナイメージ更新の流れ なにか設定を変更したい場合には手元のVSCodeにてDockerfileを編集することであとは全自動でWeb App for Containerまで展開されるようにしています。流れは以下となります。 - VSCodeにてDockerfile編集 - VSCodeからGitHubレポジトリへgit push - GitHubレポジトリとDocker Hubの連携機能によりpushが検知される - Docker Hub上でコンテナイメージの自動ビルド - Docker Hub上でのビルド完了時にWeb App for ContainerのWeb Hook URLに対してPostが実行される - Web App for ContainerがDocker Hubからビルド完了済みの最新イメージを取得 - 更新された最新イメージが実行される 体験としては、手元のVSCodeで必要な編集を行い、コミット、プッシュするのみであとは全自動のため非常に快適です。 ...

March 24, 2018 · 3 min · 胡田昌彦