技術 1 課の水本です。 最近 Terraform のリファクタリングを行っているのですが、ベストプラクティス迷子になっています。 HashiCorp でも明確な方針は打ち出していない為、Terraform を利用する各プロジェクトで方針を決めているのが現実のようです。 今回は私が出会ってきた問題と、それについての対応、見解を書き連ねていきます。 あくまでも私が思ったことですので、「こうしたほうがいいよ！」というネタも募集しています。 workspace 使うのか使わないのか問題 結論として、私自身は workspace という機能を知ったものの、使うことは考えませんでした。 Terraform では workspace という個別のエリアを設けることが可能で、これを prod や staging と命名し作成しておくと、完全に環境を分離できるというメリットがあります。 ただしデメリットと
Google Kubernetes EngineがWindows Serverコンテナを正式サポート。KuberntesでWindowsの本番用アプリケーションを実行可能に Googleは、Google Kubernetes EngineでWindows Serverコンテナの正式サポートを開始したと発表しました。 これによりGoogle Kubernetes Engineを本番環境とした、Windows Serverコンテナ化したWindowsアプリケーションを実行可能になります。 Kubernetes自身は2019年3月にリリースされたKubernetes 1.14とそれ以後でWindows Serverコンテナを正式サポートしています。これがGoogle Kubernetes Engineに取り込まれ、同社のマネージドKuberntesサービスとしては2020年1月にプレビュー版とし
7 月に開催された「JAWS-UG 三都物語 2014」でも発表したとおり、自分が関わっているプロダクトをオンプレミスから AWS に移行しました。 JAWS-UG 三都物語 2014 に登壇しました 移行して 2 ヶ月ほど経ちましたが、目立った障害もなく安定した運用を続けています。スライドでも少し触れていますが、これまでのやり方を大きく変えるキッカケにもなりました。 今回は「オンプレミスから AWS に移行して変えた 3 つのこと」と題して、社外に公開できる範囲でご紹介します。 稼働中のサーバに変更は加えない いわゆる Immutable Infrastructure の考え方を取り入れました。最初は流行りに乗りたかったという気持ちが大きかったのですが、今では昔のやり方にはもう戻れません。 オンプレミスでは本番稼働中のサーバにログインして何か変更するということが当たり前に行われていました
Ansible Tutorial July Tech Festa にて開催されたハンズオンの資料が公開されていたことに刺激され、Chef の代わりに Ansible を使う資料を作りました。 Ansible を使って WordPress サーバーのセットアップを行い、ServerSpec でテストを行います。 まだ Ansible を試し始めたばかりで自分の勉強がてら書いています。 Puppet にも Chef にも乗り遅れたので Ansible に飛び乗ってみようかと。 GitHub Repository Ansible Tutorial Wiki 2013年08月13日 一段落 コピペで動かないところを全体的に修正しました。今後は 詳細ページ Wiki を充実させていきます 2013年09月09日 role についての追記しました 2013年12月22日 リニューアル Ansible
2. Agenda ๏ 自己紹介 ๏ 本セッションについて • 本セッションの扱う対象である Ansible とは何か？ • 本セッションの対象者 • 本セッションで話すこと・話さないこと ๏ Ansibleを使う前に思いそうなこと • Ansibleを使うと何が嬉しいのか？ • 他の類似ツールとは何が違うのか？ • Ansibleを動かすのに必要なシステム要件は？ • どんな企業が実際に使っているのか？ ๏ Ansibleの基本的な使い方 13年9月15日日曜日 3. Agenda ๏ 自己紹介 ๏ 本セッションについて • 本セッションの扱う対象である Ansible とは何か？ • 本セッションの対象者 • 本セッションで話すこと・話さないこと ๏ Ansibleを使う前に思いそうなこと • Ansibleを使うと何が嬉しいのか？ • 他の類似ツールとは何が違うのか？ • Ansib
はじめに DockerでコンテナイメージをbuildするときにはDockerfileにOSイメージの指定や導入パッケージ、実行したいコマンドなどを記述してパッケージングします。 このDockerfileはほぼコマンドべた書きのような形なので難しいわけでは無いのですが、実行処理が多くなればなるほど長く読みづらくしまうし、テストも大変です。また既にChefやPuppet、Ansibleなどの構成管理ツールを用いているのであれば、既存の資産をうまく流用したほうが楽が出来ます。 ということで、Dockerfileにはほとんど仕事をさせずに、Dockerfileからchef-soloをキックしてコンテナをプロビジョニングしてみました。 やってみた ファイル構成は以下のような形です。今回はopscode謹製のbuild-essentialをレシピとして用意しました。 . ├── Dockerfile
昨年からImmutable Infrastructureという言葉が出始めて、サーバーを簡単に作って壊すという潮流が出始めました。また、サーバー管理を簡単にするツールとしてDockerというものが脚光を浴びており、いまどきのサーバー管理者に受け入れられてきました。 今回は、そのDockerをインストールしてLAMP環境を構築するステップを見ていきたいと思います。 Immutable Infrastructureとは？ IaaS型のクラウドやVPSの台頭によって、簡単に仮想サーバーが立ち上げられる環境が整ってきました。 とはいえ、サーバーの立ち上げをするのはシステム構築時と、システム規模を大きくする時に限られ、サーバーの動作を変えたり、アプリケーションのアップデートをするときは、稼働しているサーバーの中身を修正するというのが従来のやり方でした。 しかしImmutable Infrastruc
Immutable Infrastructure Conference #1 : ATND でLTしてきた。 内容はきれいにゴミを捨てましょうという話以上のものは特にない。 背景の説明が少し雑だったので補足すると、Jenkins のジョブスクリプトで、git push する度に docker run していたら ゴミがどんどんたまっていったという感じ。 1 push あたり、アプリコンテナ、DBコンテナとか合わせて3コンテナぐらい起動してるから開発が活発だと、どんどんゴミがたまる。 さらに補足すると、Device mapper がらみのゴミは、aufs 使うとかなり解決できそうな感じはしてる。 (Device mapper だとブロックデバイスレベルでイメージ差分を表現するので、デバイス毎(差分)毎に mount が走るみたいな実装になってるけど、aufs だとファイルシステム単位で複数の
Engine Yardを含むさまざまな場面で利用が広がったChefですが、その動作原理やアーキテクチャについてご存じない方もいることに気が付きました。細かなアーキテクチャを理解しなくても使うことができるというChefの長所を示しているともいえますが、細かな挙動を制御する際にはやはり動作原理などの知識があると役立ちます。 今回は表題のとおりレシピが実行される際のサイクルについてあまり知られていない部分を紹介します。 Chefの実行サイクルとリソースコレクション Chef(Chef Client、Chef Solo)が実行された際には直ちにサーバの設定が始まるわけではなく、さまざまなステップ毎に処理が実行されます。大まかには下記のようなステップになります。 Chef Serverとの通信、認証処理 Chef Serverからのクックブック、データの取得 クックブックのコンパイル ノードの設定
自動化ツールの必要性 昨今、仮想化およびクラウドの普及に伴い、サーバを短時間で増設することが容易になってきました。例えばユーザアクセスが増えてシステムの負荷が高くなった場合、サーバそのものは即座に準備できるようになりました。しかし、システムの設定は別途実施しなければいけないという状況も多々見受けられています。 サーバの台数が少なければ一台一台構築や設定を行えますが、何百台ものサーバを扱うとなると時間がかかって迅速性は失われてしまいますし、多くの人手が必要となれば設定の間違いが起こる可能性も高くなるでしょう。そして管理するサーバが増えたとしても、それらを管理する人は増えていないのが現状です。 そのため、サーバ構築とともにアプリケーションやミドルウェアの設定をも実施する自動化ツールが注目されています。 Chefとは Chef（シェフ）は、米Opscode社が提供するクラウドコンピューティングを
2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。
リソース監視はちゃんとしないとと思って、gangliaを入れてみました。 gangliaに関しては、 * クラスタリングできる * 一覧性が優れてる * プラグインがそれなりに豊富 * Nagiosとの連携が取りやすそう * yumでサクッと入れられる(fedora16の場合) ってことで試用してみました。 gangliaは日本語のドキュメントがなくて大分苦労しました・・・・ ganglian自体の概要は@yuzorockさんのスライドに詳しく載っています！ CloudForecastも考えたのですが、fedora16でうまくperlのモジュールが動かず断念しました。 ## 構築 今回、監視+表示をするサーバーをホスト、監視される側のサーバーをクライアンとします。 gagliaはホストでgmetadとgmond、クライアントでgmondのデーモンを動かす必要があります。 **ホストサーバー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
