AnsibleとDocker、なぜそしてなぜ？

DockerとAnsibleの技術コミュニティには非常に多くの関心が寄せられています。この記事を読んだ後も、この関心を共有してください。 また、Railsアプリケーションのサーバーと環境をセットアップする際に、AnsibleとDockerの実用的なアプリケーションのスキルを習得します。



「Herokuを使用するだけではどうですか？」と尋ねます。

まず第一に、DockerとAnsibleは、あらゆるホスティングプロバイダーのあらゆるマシンで実行できます。 第二に、利便性よりも柔軟性を好みます。 同様に、Webアプリケーションだけでなく、何でも実行できます。 そして最後に、私は私の魂の中で実験者なので、それがすべて一緒に機能する方法を理解することを楽しんでいます。 Herokuの基本的な基盤は、Linuxコンテナーです。 同じテクノロジーがDockerの中核にあります。 実際、Dockerのモットーの1つは「コンテナー化は新しい仮想化です」です。

なぜAnsibleなのか？

Chefを4年間積極的に使用した後、コードとしてのインフラストラクチャは非常に退屈になりました。 インフラストラクチャを管理するコードにより多くの時間を費やしましたが、インフラストラクチャ自体には費やしていません。 どんな小さな変更でも、わずかな利益のために多くの努力が必要になります。



Ansibleでは、一方でインフラストラクチャを記述するデータがあり、他方で他のコンポーネントの相互作用間に制限があります。 このモデルははるかに単純で、はるかに速く移動できるため、私のインフラストラクチャの実行内容に集中できます。 Unixモデルと同様に、Anisibleは、無限の方法で組み合わせることができる単一の責任モジュールを提供します。



AnsibleにはPythonとSSH以外の依存関係はありません。 彼女は、リモートマシンにエージェントをインストールする必要はありません。作業後にゴミを残しません。 さらに、クラウドのパッケージマネージャーからデータベースまで、すべてを管理するためのモジュールの標準ライブラリが付属しています。

なぜDockerなのか？

Dockerは、プロセスをマシンにデプロイする最も信頼性が高く便利な方法として位置付けています。 mysqldからredisまで、Railsアプリケーションで終わるものであれば何でもかまいません。 gitスナップショットおよびコード配布と同じ効率的な方法で、Dockerはプロセスでも同じことを行います。 このプロセスを実行するマシンに関係なく、このプロセスを開始するために必要なすべてのものが提供されることが保証されます。



DockerコンテナとVMを比較する主な、しかし理解できる間違い。 唯一の責任の原則がここに適用されます;コンテナごとに1つのプロセスを開始すると、変更可能性とサポートが簡単になります。 このモデルは、Unixの哲学で時の試練に耐え、アクションの強固な基盤を提供します。

カスタマイズ

ターミナルを離れることなく、AWS、Linode、Rackspace、またはDigitalOceanのいずれかのホスティングサービスでAnsibleからカスタマイズされたマシンを取得できます。 具体的には、Ansibleを使用して、Amsterdam 2リージョンのDigitalOceanに2 GBのメモリを持つ新しいドロップレットを1分25秒で作成します。 さらに1分50秒間、Dockerおよびその他の設定でカスタマイズされたシステムを取得できます。 基本システムができたので、アプリケーションをデプロイできます。 プログラミング言語またはデータベースを構成しなかったことに注意してください。 Dockerはこれを自分で処理しました。



Ansibleは、リモートマシン上でSSHを介してすべてのコマンドを実行します。 ローカルssh-agentにある私のSSHキーは、Ansible SSHセッションを通じてリモートで共有されます。 リモートマシンで、アプリケーションのコードが複製されるか、gitでの認証にデータが不要な場合、ローカルマシンから転送されたssh-agentが認証に使用されます。

Dockerとアプリケーションの依存関係

ほとんどの開発者は、カーネルのバージョン、Pythonのモジュール、Ruby gem、またはアプリケーションに必要なnode.jsモジュールを正確に示しているのに面白いと思いますが、データベースサーバーやキューサーバーなどの重要なことになると、それを使用します現時点で利用可能なもの。 これがDevOps運動の理由の1つだと思います。開発者は、アプリケーションを実行する環境に責任を負います。 Dockerは、既存のプラクティスに実用性と自信を少し加えることで、このタスクをより簡単にします。



私のアプリケーションは、 .docker_container_dependencies



ファイルを含むMySQL 5.5やRedis 2.8などのプロセスへの依存関係を定義しています

 gerhard/mysql:5.5 gerhard/redis:2.8
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Ansibleプレイブックはこのファイルを参照し、Dockerに画像のインデックスから正しい画像を取得してコンテナーとして実行するように指示します。 また、これらのコンテナはアプリケーションのコンテナにリンクされています。 コンテナリンクの操作に関する詳細情報が必要な場合は、Docker 0.6.5の発表をご覧ください。



私のアプリケーションには、Ruby Dockerイメージに固有のDockerfileも付属しています。 イメージがインストールされると、Dockerfileの手順により、正しいバージョンのRubyがインストールされます。

 FROM howareyou/ruby:2.0.0-p353 ADD ./ /terrabox RUN \ . /.profile ;\ rm -fr /terrabox/.git ;\ cd /terrabox ;\ bundle install --local ;\ echo '. /.profile && cd /terrabox && RAILS_ENV=test bundle exec rake db:create db:migrate && bundle exec rspec' > /test-terrabox ;\ echo '. /.profile && cd /terrabox && export RAILS_ENV=production && rake db:create db:migrate && bundle exec unicorn -c config/unicorn.rails.conf.rb' > /run-terrabox ;\ # END RUN ENTRYPOINT ["/bin/bash"] CMD ["/run-terrabox"] EXPOSE 3000
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初のステップは、アプリケーションのすべてのコードをDockerイメージにコピーし、前のイメージによって追加されたグローバル環境変数をロードすることです。 たとえば、Ruby DockerイメージはパスをPATHに追加して、正しいバージョンのRubyを正しくロードします。



次に、このコンテキストでは必要ないため、git履歴を削除します。 すべてのgemをインストールしてから、テスト専用に実行される/ test-terraboxファイルを作成します。 このすべての目的は、アプリケーションとそのすべての依存関係をチェックする「カナリア」バージョンを用意し、アプリケーションを実際に起動する前に、すべてのDockerコンテナが正しくリンクされ、すべてのテストが正常に合格することです。



新しいコンテナの起動時に呼び出されるコマンドは、CMDステップで定義されます。

start / run-terraboxコマンドは、テスト実行プロセスの直後に、ビルドプロセスの一部として定義されます。



Dockerfileの最後の命令は、ポート3000をDockerコンテナー内からDockerが実行されているホストマシンに転送します。 サーバーまたはロードバランサーがコンテナアプリケーションへのリクエストをプロキシするために使用できるもの。

Dockerコンテナー内でRailsアプリケーションを実行する

約100個のgemと多くの統合テストがRailsの下から実行される平均的なRailsアプリケーションの場合、ローカルDockerイメージなしで2GBと2基の原子力マシンで実行するには8分16秒かかります。 このマシンにすでにRuby、Mysql、およびRedisのイメージがある場合、4分45秒かかります。 さらに、アプリケーションの参照イメージが既にある場合、2分23秒かかります。 遠近法で見ると、MySQLやRedisなどの依存関係を含む新しいRailsアプリケーションのデプロイには2分しかかかりません。



また、アプリケーションの展開には、エンドツーエンドで1分かかるすべてのテストの起動が含まれることにも注意してください。

誇張することなく、Dockerは継続的な統合の単純な手段になります。テストが失敗した場合、またはテストに合格したときに新しいアプリケーションコンテナーが最新バージョンで起動した場合、Dockerは研究用のテストコンテナーのみを予約します。 突然、お客様に新しいコードを数分で確認できます。これにより、オペレーティングシステムレベルでアプリケーションの他のバージョンから隔離されることが保証されます。 数分でロードする従来のVMとは異なり、Dockerはこれに数秒を費やします。 さらに、Dockerイメージを作成し、アプリケーションの特定のバージョンのすべてのテストに合格したことを確認したら、そのイメージをプライベートレジストリにアップロードし、Dockerを備えた他のマシンでロードして、新しいコンテナーとして起動できます。これらすべてを数秒で。

おわりに

Ansibleにより、インフラストラクチャ管理プロセスを再確認できました。 Dockerは、最も重要な開発ステップの1つである配信フェーズに関して、自信と安定性を与えてくれました。 組み合わせて、それらは比類のないです。



完全にカスタマイズされたRailsアプリケーションをゼロからわずか12分で取得することは、どの標準でも印象的です。 基本的な継続的インテグレーションシステムを無料で入手できます。アプリケーションのさまざまなバージョンを並べてプレビューできます。同じマシンで実行されている「動作中」バージョンに影響を与えず、非常に強力です。 それは私を喜ばせ、記事の終わりに達すると、あなたが私の喜びを私と分かち合うことを望むだけです。