Insightsを作成します。Insightsの作成が完了し、以下のような画面を見ることができます。後ほど使用しますのでメモしておいてください。以下の手順でPhaiをcloneして、CakePHPのサンプルの設定をします。指定してサンプルアプリを実行します。Keyを指定してください。Insightsに送信されます。hereをクリックします。以下のように、アクセスログが、レスポンスタイム付きで表示されます。ポータル上に反映されるのに数分かかりますので、少しお時間をおいてから確認してください。ような存在しないページにアクセスしてみます。Insightsに送信されてエラーの内容を確認することができます。Insightsへの転送は行われません。環境変数などを利用して、実行環境ごとに、ログレベルを設定したり一時的にデバッグログを有効にするなどの切り替えが簡単にできるようになっています。\ApplicationInsights\Channel\Contracts\Severity_Level::Warning);サンプルコードの簡単な解説config/bootstrap.phpの末尾で、環境変数をもとに設定情報を保存しています。$client);src/Application.php内で以下のように、Phaiを登録しています。Insightsを導入できることがご理解いただけたのではないかと思います。Insightsを利用できるようにしていく予定です。DevOpsのワークショップを開催していただきました。pipeline構築の一例を紹介したいと思います。DevOps全て日々成長を続けていますのでここで紹介する内容は執筆時点での情報なのでご注意下さい。(以下、AKS)は、フルマネージドなKubernetesクラスタを提供するサービスです。(VM)です)のサイズ、ノード数により課金されます。Registoryに、アプリのコンテナイメージを用意した状態で作業を開始しました。Cacheを使用します。CacheはプレミアムプランでないとVNet対応機能が使えません。プレミアムプランは今回のアプリ規模にはマッチしないということで、VNetへの配置は諦め、スタンダードプランを利用し、IPアドレスで制限する形にすることにしました。CLIを使って順次構築していきました。今回は、初期開発ということもあり、配置するアプリケーションもシンプルな構成なので、クラスターも極力シンプルな構成を取る方針で下記のような構成をとりました。DevOpsでビルドが始まり自動でリリースされる方式を取りました。apiapiに関しては、B/Gデプロイメントに近い以下のような形を取りました。最後の古いデプロイメントの削除に関しては、ビルド番号がエラーなどで飛んでしまうなど自動化するためにはいくつかハードルがあるため、現状は手動で削除する形をとっています。DevOps側の詳細については後述します。今回のワークショップでは、モブプログラミングの様なフォーマットで、定期的にドライバを交代しながら作業を進めました、そのおかげで参加した全員が実際の構築を体感できたので、後半では活発にアドバイスすや意見が出て全員の理解度が上がっていることを体感できました。この形式は今後会社の業務でも取り入れていきたいと思います。最終的にクラスタの構築は、弊社のイケメンエンジニアたちがTerraformで自動構築できるようにしてくれて、いつでもクラスタを再現できるようになりました。AKSクラスタの構築に関する詳細は近いうちにブログにまとめられるはずなので、公開されたら追記します。DevOpsのオーガニゼーションがない場合は、https://dev.azure.comにアクセスし作成します。今回の扱うアプリはPHP(CakePHP)を使っていますが、現状PHPのテンプレートのデプロイターゲットにはAKSが含まれていません。DevOps/AKSの利用ということで、AKSへのデプロイ方法の参考にするために、Java/SpringのテンプレートをつかってAKSへデプロイするプロジェクトを作成し、それをベースにカスタマイズして行く方法をとりました。雛形となるテンプレートとしてJavaを選択します。フレームワークは何でもいいのでとりあえずSpringを選択します。デプロイ先はAKSを選択します。Existingを選択して、デプロイ先のAKSクラスタを指定します。Doneをクリックすると構築が始まるのでしばらく待ちます。Portalに以下のような画面が現れます。DevOpsから、自動デプロイできる環境ができますので、内容を確認して各自の環境に合わせてカスタマイズしていくと良いでしょう。作成されるpipelineを直接直すのではなく、pipelineを新規に作成、サンプルを参考に構築していくのが良いと思います。今回のアプリは、JWKトークンを利用するため、ビルド時に証明書のアクセス権などを設定する必要がありますが、証明書をリポジトリに含めることは避けるべきです。filesという機能があることを発見したのでこの機能を利用してビルド時に証明書を取得することにしました。filesタブがあるのでここで証明書ファイルをアップロードします。タスクを使用してダウンロードすることができます。Lineタスクなどを使用して、所定の場所に移動するなどして利用可能です。groupとしてまとめて再利用することができます。選択すると作成することができます。groupの内容を編集することができます。deplyment.yamlの更新テンプレートでは、hemlを利用してデプロイを実施しているのですが、今回はビルド時にdeployment.yamlのタグやバージョンを更新してapployする方式をとっています。下記のようにsedコマンドを使用して、テンプレート内のVERSIONという文字列を、実行中のビルド番号に置換して実現しています。様にプレフィックスをつけています。pipelineで利用するために、Artifactディレクトリにコピーする必要があります。コピーすることで、後続のpipelineに受け渡すことができます。pipelineはこんな形になりました。jobの前に、UnitTest用のJobを実行し、正常に終了したらbuildに進むように設定しています。group化しています。pipelineはこんな感じになりました。approvalsを有効にして、担当者の承認後に進むように設定しました。taskを指定してapplyしています。blueでは、blue_service.yamlをapplyしています。まとめここまでの環境を設定するのは、かなり大変ですし、いろいろとハマったところもあるので、ワークショップで寺田さんにサポートしてもらえなければ挫折していたかもしれません。本当にありがとうございました。DevOpsは、VSTSで蓄積されたノウハウが詰まっていて凄く良いと感じました。OSSを使ったアプリでも問題なく使えます。このプロジェクトを通して使い倒してノウハウが溜まったらまたいつか紹介できるようにしたいと思います。Kubernetesを利用する場合でも、環境や思想はそれぞれ異なるので、すべての環境が今回の形で対応できるわけではないでですが、構築を検討している方の参考になると嬉しいです。実際のアプリの開発は、これからが本番なので気合を入れて開発を進めていきたいと思います。CD何度もつぶやいたことがある気がするけど、予定が詰まっているときに限って仕事と関係ないコードを書いてしまい、結局ブログまで書き始めてしまった渡辺です。DevOpsazure.microsoft.comCI/CDを実現するためのサービスで、以下のような機能が含まれています。Artifactsは試していないのでよくわかってないです...。Projectの作成を開始すると下記のように、ウィザード形式で設定が進みます。次にFrameworkの選択です。次にDploy先のサービスを選択します。Containersを選択します。最後に、プロジェクトの設定をします。Registryの細かな設定ができます。Portalに以下のような画面が現れます。Projects画面右上の、エンドポイントURLをクリックするとdeployされたサイトを見ることができます。作成直後のWebサイトここまでで、10数分くらいですかね。これで、リポジトリからPipeline経由でデプロイされる環境ができちゃいます。遷移すると公開鍵を登録することができます。PHPをdeployすると初期状態では、リポジトリには下記のようなシンプルなPHPアプリが生成されています。containerRegistry-template.jsonちょっと中身を覗いてみましょう。ベースにしているようです。installしています。installApplication/index.phpautoloadして、application-insightsにリクエストログ投げているだけのほぼ静的なページです。templateが保存されています。要は、80でWebサーバさえ上がっていればOKそうです。配置がちょっと気になりますが...。DevOps内の流れ初期状態では、Pipeline内にはBuilds/Releasesの2つにpipelineが設定されています。BuildBuildには以下のようなpipelineが設定されています。RegistryにpushPipelines/BuildReleasesReleasesには以下のようなpipelineが設定されています。Containerを作成するコンテナをdeployするPipelines/Releasesデプロイのオプションには、slotにデプロイさせる設定などがありますね。まとめこんな感じで、単純なWebアプリをデプロイするpipelineがすごく簡単に構築できます。deploymentをするなど、普段別サービスを使ってやっていることを置き換えていろいろ試してみようと思います。CodePipeline新しい職場もあっという間に半年経ちますが、おかげさまで元気で毎日忙しい日々を過ごしているAWS初心者のわたなべです。CodePipelineです。aws.amazon.comCodePipelineは、Jenkinsやcircleciのように、CI/CDを実現するためのサービスで、AWS謹製ということでAWSの他のサービスと連携しやすいのが特徴かと思います。Fargeteを使用してBlue/Greenデプロイメントを実現するということで、aws-examplesにある以下のサンプルを参考にしています。ブランチがFargate上でB/Gデプロイメントを実現するサンプルで、ざっくり以下のような流れでB/Gデプロイメントを実現しています。submoduleとして構成されています。submoduleはサポートされていません。リポジトリをクローンすることを検討してください。書かれているので実際に試してみました。ディレクトリが含まれていないので無理でした。"https://$GITHUB_TOKEN@github.com/bar/foo-api.git"実際のビルド処理、pushする処理及びartifactとして次の処理に渡すbuild.jsonは、以下のようなスクリプトで生成するようにしてみました。このスクリプトでは、変更されていないsubmoduleのビルドを省くために、コンテナのタグにgitのhashを使うよう変更しています。フェーズで強引にjq-1.5をインストールしています。権限を追加する必要があります。...そして、最終的なBuild処理の定義はこんな感じです。該当箇所も修正する必要があります。submoduleに対応できそうです。AWSはあまり使ったことがなく、試行錯誤しているところなのでもっといい方法がないか含め引き続きいろいろ試してみます。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。