API構築の基礎を学んだ。QConは、開発者コミュニティにおける知識とイノベーションの普及を促進することで、ソフトウェア開発に力を与える。実務者主導のカンファレンスであるQConは、チーム内のイノベーションに影響を与える技術チームのリーダー、アーキテクト、エンジニアリングディレクター、プロジェクトマネージャー向けにデザインされている。Sheehy氏は、人工知能ハイプ時代における責任ある開発者としてのあり方について、洞察に富んだ開会基調講演をした。Grizzanti氏が、「スタッフ・プラス」への道と、それを「科学」というより「芸術」としてとらえ、芸術を創作することとソフトウェアを創作すること、そして組織のダイナミクスに対処することの類似性について語っている。Codeを採用する:確認するべき6つの適性LCNC(ローコード/ノーコード)プラットフォームは、プログラマーだけでなくプログラマーでなくても、最小限のコーディングとワンクリックのデプロイメントで、アプリケーションソフトウェアを開発できるよう設計されている。ドラッグ&ドロップ方式のインターフェースなどを利用することで、開発・デプロイメントプロセスを簡素化し、効率的なアプリケーション開発とデプロイメントを実現する。Hashimoto氏は,大規模ソフトウェアシステムの安全なデリバリという究極の目標に対して,インフラストラクチャのプロビジョニング,コンテナベースあるいはクラウドアプリケーションのライフサイクル管理といった作業のオーケストレーションを行う上で,HashiCorpのTerraformやConsulなどのツールをどのように利用するか,というテーマを論じた。HashiCorpの共同創業者で,VargrantやPackerの開発者であるHashimoto氏の講演は,ソフトウェアシステムというコンテキストにおけるオーケストレーションの究極的な目標は,大規模なアプリケーションを安全にデリバリすることにある,と述べることから始まった。アプリケーションのパッケージング,イメージ記録,実行といった問題に対する解決策がコンテナ技術だ。Dockerでは,これらの問題をDockerイメージ,Dockerレジストリ,Dockerデーモンでそれぞれ解決している。インフラストラクチャのライフサイクルやプロビジョニング,モニタリング,ディスカバリとコンフィギュレーションの提供,セキュリティ,アプリケーションライフサイクル管理といった課題は依然として残ったままだ。Hashimoto氏は,開発者と運用担当者が“インフラストラクチャを安全かつ効果的に構築,結合,ローンチ可能”にするものとして,Terraformを紹介した。Language(HCL)で記述されたコンフィギュレーションファイルを使用して,コードによるインフラストラクチャ構築を行う。HCLはlibuclにヒントを得た,JSON完全互換の言語で,サーバやコンテナ,ロードバランサ,データベースなどをコマンドひとつで定義し,提供することができる。インフラストラクチャの変更のプレビューを生成して“diff”で比較し,議論し,プルリクエストを行うことが可能で,GitなどのDVCSを利用した通常の開発ワークフローとほとんど変わりがない。サービスディスカバリとコンフィギュレーションはConsulで処理することができる。“サービスfooはどこにある?”,“マシンfooの稼働状態は?”,“デバイスfooのコンフィギュレーションは?”といった質問は,すべてConsulで回答可能だ,とHashimoto氏は言う。APIの他,“レガシフレンドリ”なDNSでも提供される。(あるいは,不正なノードについては報告しない)。Consulは,コンフィギュレーションの高可用性ストレージ用として利用可能なキー/バリューストアも提供する。運用担当者は,“大規模なコンフィギュレーション管理プロセスを必要とせず,ノブを回す”ことが可能だ。デフォルトはローカル動作だが,マルチデータセンタ対応に構成することもできる。Hashimoto氏は,Consulがコンテナの中外問わずに実行することができる点も紹介している。Consulはその実行速度とスケーラビリティによって,将来的なアプリケーションの‘コンテナスケール’や,そこで生じる問題に対しても対応可能となっている。Hashimoto氏に連絡を取り,TerraformやConsul,コンテナ技術について質問することにした。こんにちはMitchell,InfoQコミュニティの質問への回答に同意してくれてありがとう。私が一番よく知られているのは,多分Vagrantの作者としてでしょう。Vaultの作者としての方が知られています。これらツールはすべて,世界中のWebサイトで大規模に運用されています。そのようなツールの開発に関われたことを,本当に誇りに思っています。私は自分自身のことを“オートメーション馬鹿”だ,と説明しています。この仕事と,コンピュータにそれを教え込むことが大好きなのです。今はこれをDevOpsのフィールドでやっていますが,これまでは教育やコミュニティ(フォーラム),ゲームなど,さまざまな領域で行っていました。Terraformは昨年登場したツールです。初期設定とメンテナンスの両面からインフラストラクチャの定義と構築を行うためのツール,と説明すればよいでしょうか。CloudFormationなどのツールと比較するかも知れませんが,Terraformを深く知れば,はるかにパワフルなツールであることが分かると思います。Terraformは任意のクラウドプラットフォーム上でインフラストラクチャを生成して,それらを組み合わせることができます。EC2インスタンスを生成して,そのインスタンスのIPアドレスをCloudFlare内のDNSレコード設定に使用するようなことも可能です。Terraformがデータセンタ/インフラストラクチャ自動化において担う役割について,特に機能面で重複するAnsible(あるいはPuppetやChefなど)との関係についての質問をよく見かけます。Ansibleをフルタイムで使用したことがないので,申し訳ないのですが,自信を持って比較することはできません。ChefやPuppetなどとの関係についての指針は提供できます。Chef/Puppetなどの構成管理ツールは,Terraformの比較対象ではありません。リソースの初期生成(サーバを起動しロードバランサに接続するなど)の管理が可能という意味で,オーバーラップする部分はありますが,その部分でも簡単に区別が付きます。構成管理ツールに対して,Terraformには,コアエンジンのレベルで2つの大きなアドバンテージがあります。Terraformでは,任意のリソース内部にあるリソースの属性を参照することが可能です。これにより,AWSインスタンスを起動してIPアドレスを参照し,DNSレコードを設定する,といった操作が可能になります。ChefもPuppetも変数をサポートしていますが,属性にアクセスすることはできません。IPアドレスのような情報は事前参照ができないので,これはとても重要なことです!実行時にのみ存在する値という意味で,Terraformではこれを“計算(computed)”属性と呼んでいます。ひとつのアドバンテージは,リソースのライフサイクル管理が複雑であることです。ChefやPuppetでは,“古いリソースを削除する前に新たなリソースを生成する”という定義は簡単ではありませんが,Terraformではごく基本的なライフサイクル機能です。旧サーバを削除したいと思うでしょう。この種のロジックが,Chef/Puppetでは表現が難しいのです。それから,半分冗談のような話ですが,Terraformからリソースを削除すれば,Terraformはそのリソースを削除します。Puppet/Chefでは,リソースを削除済みであると明示的にマークしなくてはなりません。構成から削除したことを検出してくれないのです。CloudFormationのようなベンダ/プロバイダ特有のインフラストラクチャツールは,ターゲットプラットフォーム向けにチューニングされているため,きめ細かい設定のコントロールが可能です。TerraformでAWSサポートを開発するために,一人をフルタイムで採用したのですが,ユーザから要求されていたリソースのほぼすべてをカバーするのに,1ヶ月も掛かりませんでした。先月(私たちと仕事を始めて2ヶ月目)には,CloudFormationに先行して,さまざまな機能を追加することができたのです。心配の解消にはこれで十分です。加えておくと,Terraformのリソース記述は極めて簡単です。これを可能にしたのは,コミュニティからのコントリビューションの大幅な拡大です。将来的には,”新機能サポートのリードタイム”の面では,誰よりも先行できると思っています。AWSに関してだけではありません。Cloudの,未発表の機能でさえ既にサポートしています。一般的に私たちは,これらのベンダと密接に協力して,彼らのプラットフォームを迅速にサポートできるようにしています。彼らはベンダ独自のツーリングのユーザを失う代わりに,プラットフォームに支払うユーザの数を増やす,私たちもユーザを増やす,ということです。TerraformがプロバイダAPIの固有部分(SSLロードバランサでの暗号化サポート設定のような)をサポートしない場合,ユーザはこのような変更をTerraformの外で行わなくてはなりません。Terraformが管理しないプロパティ(SSLロードバランサの暗号のような)に関しては,その変化を偏差としては監視しませんし,Terraformの動作に影響することもありません。そのプロパティがサポート対象になっても,それが設定と一致している限りは偏差として見ることはありませんから,動作の変わることはありません。単純なことだと思います。インフラストラクチャベンダやプロバイダの提供するAPIやSDKは,時間の経過とともに変わります。インフラストラクチャベンダは,APIの互換性を十分に確保しています。AWSを見てください,2006年当時のAPIプロトコルが今でもサポートされているのです!ですから,APIレベルではあまり心配していません。問題なのはライブラリのレベルです。TerraformはGo言語で記述されていて,ライブラリは静的にコンパイルされているので,リリース済のバイナリが影響を受けることはありません。上流ライブラリの変更が原因で,Terraformのマスタブランチのコンパイルが突然止まった,というケースが過去にありました。困ったことですが,これにはGoに追加される予定のベンダリングサポートで対処するつもりです。新機能に関しては,主要なインフラストラクチャプロバイダは現在,SDKの完全自動生成に移行しつつあります。Terraformには,非常に大規模な企業が何社も投資しています。1.0に向けて,容易に実行可能なマイグレーションパスを必ず用意します。これまでは自動マイグレーションを用意してきました。状態には“バージョン”フィールドが含まれているので,構造のバージョニングに使用しています。現在のTerraformは,アップデートを実行する前に,前回実行時のインフラストラクチャ状態を格納した“.tfstate”ファイルが必要です。1.0よりも,多分ずっと前になるでしょう。推測で言うならば,0.8ではないでしょうか。インフラストラクチャプロバイダのデータは,Terraformのフルコンフィギュレーションよりもずっと少ないので,このプロセスは非可逆ということになります。それでも,可能な限りの設定を生成できることには意味がありますから,それを実現したいと思っています。0.5ではマルチプロバイダサポートが追加されて,複数のプロバイダのインフラストラクチャをひとつのファイルに(AWSのマルチリージョンのように)定義できるようになりました。Terraformは同一ディレクトリにあるすべての*.tfファイルをロードしますから,ファイルの分割は可能です。モジュールを使うことで,分割だけでなく,パラメータ指定も可能になります。Terraformの目標は十分な選択肢の提供にあるので,必要以上に複雑になることはありません。先日,現代的なデータセンタの自動化に注目した新たなカンファレンスとして,“Hashiconf”の発表がありました。私たちには,非常に大きなコミュニティがあります!私たちは過去一年間,私たちのツールに興味を持ち,考えを同じくする人たちが集まって,その知識を共有するための,HashiCorpコミュニティイベントを作り上げるため,さまざまなことを尋ねてきました。これがHashiConf,すわなちHashiCorpのツールと,現実社会におけるプロジェクト間の対話にフォーカスしたカンファレンスなのです。“HashiCorpの製品Xの使い方”といった講演ではなく,もっと一般性のある,“X社は製品Yと非HashiCorpプロジェクトZをどのように活用したか”というものになります。質問に答えるために時間を頂いて,改めてありがとう,Mitchell。全部話したと思います!質問頂いてありがとう,とても楽しかったです。その他,私に連絡したいことがあれば,私のTwitterアカウントにEメールアドレスがあります。Consul”に関する詳細は,カンファレンスのWebサイトで見ることができる。毎週火曜日に前週のまとめコンテンツをお送りいたします。(日本語版は不定期リリース)25万人のシニアな開発者コミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。毎週火曜日に前週のまとめコンテンツをお送りいたします。(日本語版は不定期リリース)25万人のシニアな開発者コミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。Inc.プライバシーBT。