Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。_原文(投稿日:2019/05/17)へのリンクDockerコンテナは、いくつかのクラウドプラットフォームのうちの1つを使用してデプロイできます。ECSはFargate起動タイプを提供します。これは、EC2インスタンスではなくDockerコンテナ上でコンテナサービスを実行するためのサーバーレスプラットフォームです。問題Dockerコンテナのデプロイメントは、Dockerイメージのソースコードまたはコードビルドの変更により、更新または変更が必要になる場合があります。Dockerイメージのソースコードを変更した場合は、Dockerイメージを再構築してDockerサービスを再デプロイする必要があります。デプロイするメカニズムがないと、ECSサービスタスクを停止し、その結果ECSサービスのダウンタイムが発生します。ECSサービスの高可用性が優先され、アプリケーションを再デプロイするためにタスクを停止することは適切な選択肢ではありません。ECSやFargateなど、さまざまなAWSプラットフォームでホストされるアプリケーションの継続的インテグレーション、継続的デリバリ、継続的デプロイのためのDevOpsサービスです。ECSサービスは、ECSサービスタスクを停止することなく更新または修正することができます。CodePipelineは、Dockerイメージのソースコードの変更が一般的である動的環境でECSサービスの高可用性を提供します。CodePipelineは、図1に示すように、ソースコードの統合、ソースコードの構築、デプロイの3つのフェーズで構成されています。CodePipelineのフェーズソースコードにはGithubレポジトリを使用します。CodeBuildプロジェクトを使用します。デプロイには、起動タイプがFargateのECSサービスを使用します。Fargateにデプロイするには、次の手順に従います。前提条件はAWSアカウントです。FargateのCodePipelineによってデプロイされたアプリケーションはDockerアプリケーションです。ソースコードのレポジトリを持っているDockerイメージであればどんなものでも使うことができ、私たちはDockerイメージdvohra/node-serverを使いました。Dockerイメージdvohra/node-server.のGitHubソースコードリポジトリはこちらです。新しいGitHubソースコードリポジトリを使用する場合は、そこにDockerイメージを構築するためのDockerfileを含める必要があります。イメージのDockerfileは、Dockerイメージnode:4.6をベースにしています。Dockerfileの手順に従って、server.jsファイルをコピーします。それによって、現在のディレクトリにNodeサーバーが作成され、Nodeサーバが待機するポート8080が公開され、server.jsスクリプトでnodeコマンドが実行されます。server.jsファイルは、Nodeサーバを作成し、HTTPリクエスト/レスポンスを処理します。CodeBuildプロジェクト向けのビルドスペックの追加ビルドスペックは、ビルドを実行するためにCodeBuildプロジェクトで使用されるビルドコマンドと設定を含むYAML構文ファイルです。ビルドスペックファイルは「buildspec.yml」という名前である必要があり、ソースコードリポジトリのルートにコピーする必要があります。buildspec.ymlファイルはビルドのさまざまなフェーズを記述するためのキー・バリューのペアで構成されます。ビルドphasesはフェーズ順で表され、buildspec.ymlで必須のマッピングです。versionはbuildspec.ymlで必須のマッピングです。buildspec.ymlファイルはGitHubリポジトリに記載されています。CodePipelineにはJSON形式のイメージ定義ファイルが必要です。イメージ定義ファイルはデフォルトではimagedefinitions.jsonという名前ですが、別の名前を付けることもできます。イメージ定義ファイルにはコンテナアプリケーションを記述し、nameとimageURIの2つの属性で構成されます。nameはDockerコンテナ名を指定し、コンテナはCodePipelineを実行する前に実行されていなければなりません。imageURIは、Dockerコンテナで実行されるDockerイメージを指定します。Dockerイメージは通常、すでにECSコンテナで実行されているDockerイメージと同じです。イメージは異なる場合があり、バリエーションは通常、イメージタグのバリエーションとなります。ECSにデプロイされたNodeサーバアプリケーションに使われるimagedefinitions.jsonはGitHubに表示されています。タスク定義の作成ECSアプリケーションのタスク定義は、ECSデプロイでcontainer/sを記述します。FargateにデプロイされるNodeサーバコンテナのタスク定義を作成します。このURLを開き、まだログインしていない場合はログインします。startedをクリックしてECSコンソールにアクセスします。Definitionsをクリックします。Definitionをクリックします。Definitionで、Fargateとして起動タイプの互換性を選択します。stepをクリックします。次に、タスクとコンテナの定義を設定します。name(ノードサーバ)を指定し、Imageをdvohra/node-serverと指定します。タスク定義を図2に示します。タスク定義タスクサブネットでの接続の設定サービスを作成する前に、サービスを設定するときに使用するサブネットでインターネットへの接続を設定する必要があります。Tableにルートが一覧表示されます。デフォルトのインターネットゲートウェイと共にルートを追加する必要があります。IPアドレスが0.0.0.0/0のDestinationを持つルートを追加します。gateway.としてTargetを選択します。コンテナサービスの作成とテスト次に、図3に示すように、デフォルトのクラスタにECSコンテナサービスを作成します。Interface(ENI)がプロビジョニングされます。InterfaceのパブリックIPと同じタスクのパブリックIPをコピーします。Task>:8080を開き、Nodeサービスアプリケーションを起動します。Nodeサーバは、図4に示すようにメッセージを返します。NodeサーバレスポンスS3バケットの作成または設定CodePipelineでNodeサーバアプリケーションのソースコードをビルドし、DockerイメージをECSサービスにデプロイするために、CodeBuildプロジェクトで「出力アーティファクト」を生成する必要があります。出力アーティファクトは、CodePipelineを作成するときに選択されるS3バケットに保存されます。S3コンソールで新しいS3バケットを作成するか、またはCodePipelineの事前実行で作成されるS3バケットを選択します。次に、ソースコードをDockerイメージにビルドするために使用されるCodeBuildプロジェクトを作成します。Dockerイメージのソースコードをビルドするために使用されるDockerイメージdvohra/node-serverおよびbuildspec.ymlファイルのソースコードについては既に説明しました。Dockerイメージがビルドされた後、それはCodeBuildによってDockerハブにアップロードされます。CodeBuildプロジェクトを作成するには、ウェブブラウザでこのURLを開いてください。projectをクリックします。projectウィザードが起動します。projectで、プロジェクト名(ノードサーバ)を指定します。ProviderでGitHubを選択します。リポジトリとしてリポジトリを選択します。depthのデフォルト設定を1のままにします。Badgeのオプションを選択します。Webhookを選択すると、GitHubリポジトリでコードが更新されるたびにコードが再構築されます。SSLオプションを選択すると、プロジェクトソースに接続するときにコードビルドSSL警告が生成されます。Badgeオプションを選択すると、プロジェクトのステータスが表示され、埋め込み可能になります。CodeBuildを選択します。Systemとして、Ubuntuを選択します。ランタイム向けに、図6に示すようにDockerを選択します。ランタイムとしてDockerを選択ランタイムバージョンについては、aws:codebuild/docker:17.09.0を選択します。これはDockerバージョン17.9を表します。新しいバージョンが利用可能な場合は、新しいバージョンを選択してください。Dockerイメージを構築するのに必要なので、Dockerランタイムに対してPrivilegedオプションが自動的に選択されます。directoryを選択します。ビルドスペック名はデフォルトでbuildspec.ymlです。certificateを選択します。証明書はCodePipelineには必要ありませんが、より安全なCodeBuildのために自己署名証明書をS3からインストールすることができます。次に、Artifactsで出力アーティファクトを設定します。出力アーティファクトはCodePipelineに必要です。使用するS3バケットフォルダ名を指定してください。Pathを「/」に設定すると、バケットルートにフォルダが作成されます。typeでNodeを選択します。nameで図8に示すように、以前に設定したバケットを選択します。cacheを選択します。オプションを選択します。accountを選択します。roleオプションを選択すると、図9に示すようにこのビルドプロジェクトで使われます。Continueをクリックします。サービスロールとVPCの設定Reviewで、SourceおよびBuild環境を確認します。下にスクロールしてCreateをクリックし、CodeBuildプロジェクトを作成します。projectsに表示されます。CodeBuildプロジェクトCodeBuildによってデフォルトで作成されたサービスロールには、必要な権限の一部が含まれていません。s3:PutObjectを追加するインラインポリシーを追加して、サービスロールを変更する必要があります。追加するインラインポリシーは次のとおりです。]}CodeBuildプロジェクトのテストCodePipelineでCodeBuildを作成および設定する前にCodeBuildプロジェクトをテストして、エラーがある場合は修正します。buildをクリックしてビルドを開始します。buildウィザードが起動します。buildをクリックします。CodeBuildプロジェクトが開始され、コードがビルドされ始めます。detailsは図12のようになります。Hubに生成され、更新されたDockerイメージdvohra/node-serverを図13に示します。14.各CodePipelineステージ用にプロジェクトを作成します。Fargateサービスです。次にCodePipelineを作成します。startedをクリックします。pipelineウィザードが起動します。stepをクリックします。次に、ソースの場所を設定します。providerとしてGitHubを選択します。GitHubでGitHubに接続します。図18のようにGitHubリポジトリを選択します。Repo図19に示すように、レポジトリBranchを選択します。step次に、ビルドを設定します。CodeBuildを選択します。表示される後続のセクションは、選択したビルドプロバイダに基づきます。CodeBuildの場合、CodeBuildに関する詳細を提供するセクションが表示されます。projectを選択します。nameで、以前に作成したCodeBuildプロジェクトnode-serverを選択します。stepをクリックしてください。ステージを設定します。ECSセクションに示されているように、選択されたデプロイメントプロバイダに基づきます。nameで、デプロイされるECSサービスが作成されるクラスタを選択します。defaultを選択します。nameとしてデプロイ先のECSサービスnode-server-serviceを選択します。filenameとしてimagedefinitions.jsonを指定します。省略した場合、デフォルトのイメージファイル名はimagedefinitions.jsonになります。ファイルはソースコードGitHubリポジトリで利用可能であるべきです。stepをクリックしてください。nameを選択します。新しいサービスロールは、CodePipelineが最初に作成されたときに、自動的にIAMに作成されます。その後、サービスロールが選択できるように一覧表示されます。stepをクリックしてください。pipelineをクリックします。pipeline図28に示すように、CodePipelineが作成されます。Progressステータスで示されます。CodePipelineのSourceステージ実行中Sourceステージが完了すると、図29に示すように、そのステータスはSucceededになります。Progressで示される。図30のSucceededステータスに示されているように、Buildステージも完了しました。Stagingステージが実行を開始します。入力/出力アーティファクトの修正すべてのCodePieplineステージの設定が済んでいます。入力/出力アーティファクトの設定を変更する必要があるのはなぜでしょうか。CodePipelineによってデプロイされたECSアプリケーションの例では、デフォルトの入出力アーティファクト設定はCodePipelineを実行するのに必要なものではありません。デフォルトでは、ステージングステージへの入力アーティファクトは、Buildステージからの出力アーティファクトです。ECRにアップロードするだけのCodeBuildの場合、CodeBuildステージでは出力アーティファクトは生成されません。Stagingステージへの入力アーティファクトは、Sourceステージからの出力アーティファクトに設定する必要があります。入出力アーティファクトの設定を変更しないと、Stagingステージは失敗します。作成後に自動的に開始されたCodePipelineは失敗します。入力/出力アーティファクトを変更するには、図31に示すようにEditをクリックします。changesをクリックします。changeをクリックします。change確認ダイアログで、Releaseをクリックします。Progressステータスに示されているように、CodePipelineに対する変更が適用され、CodePipelineが最初から実行され始めます。BuildおよびStagingステージのステータスは前回の実行のものであり、現在のステージのステータスを示すものではありません。実行中のSourceステージ図35に示すように、CodePipelineのすべてのステージはSucceededのステータスで完了します。前のサービスタスクが停止し、図36のRUNNINGタスクステータスに示されているように、修正されたタスク定義に基づくタスクが実行を開始します。Networkインターフェイスから、以前と同様にそのパブリックIPを見つけます。IP>:8080を開きます。Nodeサーバアプリケーションのレスポンスを図37に示します。NodeサーバアプリケーションのレスポンスCodePipelineを再実行するためのソースコードの修正ECSサービスのレスポンスがCodePipelineなしでサービスを直接呼び出す場合と同じである場合、CodePipelineを実行する利点は何でしょうか。通常、本番環境にデプロイされたECSのソースコードは定期的に更新する必要があります。これは、Dockerイメージを再構築する必要があることを意味します。ECSサービスタスクにデプロイされたDockerイメージも更新する必要があります。Dockerイメージは、ECSベースのサービスを中断することなく更新する必要があります。CodePipelineでは、ソースコードの修正が行われるたびにCodePipelineの新しい実行が自動的に開始されます。ユーザの介入なしに、ソースコードが変更されたときにECSのデプロイが更新されます。説明するために、server.jsのHelloメッセージを変更するなど、GitHubリポジトリのソースコードをわずかに変更します。changesをクリックします。図38でSourceステージが正常に完了し、Buildステージが進行中であることが示されているように、CodePipelineが自動的に再実行されます。CodePipelineが自動的に再実行Buildステージが正常に完了すると、図39のステータスメッセージで示されるように、Stagingの実行を開始します。Buildステージが完了し、Stagingステージが開始Stagingも正常に完了しました。新しいタスクが開始されます。IP>:8080を開きます。新しいタスクが呼び出され、ノードサーバのレスポンスが図40のように表示されます。Nodeサーバのレスポンスは、server.jsから変更されたレスポンスです。Fargateにデプロイする方法について説明しました。CodePipelineを使用して、Dockerイメージのソースコードを更新し、コンテナサービスを停止せずに実行中のコンテナサービスに新しいDockerイメージをデプロイする方法を示しました。Vohra氏は、Sun認定のJavaプログラマーおよびSun認定のWebコンポーネント開発者です。EEに関連する技術記事を公開してきました。