共通しているのは、いずれも何らかのワークフローの解決を目指すという点です。そのためにHashiCorpが提案しているのは、コード化を通した自動化です。それは、効率の向上だけでなく、人手による誤りを防ぐという役割も持ちます。そのため、本来行いたい開発や運用に関する業務に集中するための仕組みを提供しています。 その一方で、実際の開発から運用に至る流れを見てみますと、各ツールを組みあわせる必要が出てきます。たとえば、次のようなケースが考えられます。 Vagrantで作った環境を、Packerでマシン・イメージ化したい Packerで作成したマシン・イメージを使ってTerraformで使いたい Terraformで作った環境を、Consulで監視・オーケストレーションしたい そこに登場するのがAtlasです。Atlasは、サイトの説明によると「開発から運用に一貫したフローを提供する」とあります。A
すごい広島113で遊んでたこと。 テスト環境を提供しないといけなくて、Dockerつかいたかったけど、今回はVagrantのBoxでベースを提供することにした。 Packerつかうと時間がかかるのでvagrant packageでつくって、Vagrant Cloudにおいたりしてました。 ちょっと久しぶりにPackerでboxをつくるかーってAtlasにいってみたら、Web上に表示されたチュートリアルにそってコマンドラインで作業するだけでBoxがつくれるようになってました。 しかも、Packerの実行をAtlasがやってくれます。しかも、VirtualboxとVMwareのイメージ両方つくってくれます。 しかも、勝手にBoxesに登録されます。 素敵です。 Atlasにサインインする Build Vagrant Boxes with Packer and Atlasというメニューがあってク
TL;DR Terraform + GitHub + CircleCI + Atlas を用いてAWSの操作を自動化した 各ツールの役割は下記のような感じ Terraform => インフラへの変更ツール GitHub => .tfファイルのバージョン管理 CircleCI => CI、Terraformをawsに対して実行 Atlas => インフラの状態を記録するterraform.tfstateの管理 インフラの継続的デリバリー - naoyaのはてなダイアリーにて、言及されていた範囲(Route53の変更、Chefの適用)をAWSの操作全体に拡大した 背景 今までの問題点 AWSの各種操作がブラウザからポチポチ業… 手作業なので誤操作に気づきにくい。事故りやすい インフラの実構成がバージョン管理出来ていない ちなみにRoute53に関してはroadworkerを用いてコードで管理済
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
