2015-01-12 8 views
13

DockerをContinuous Deliveryパイプラインで使用する最も良い方法は何ですか?Dockerを継続的に使用するにはどうすればよいですか?

ビルドアーティファクトはJar/WarではなくDocker Imageでなければなりませんか?もしそうなら、それはどのように機能するのでしょうか?Dockerをシームレスに(ラップトップ上で)開発中に使用して、CIサーバーに同じベースイメージを使用させてアーチファクトを構築させる方法はありません。

+2

コードシップは、この質問に関する良い記事を書いています。https://blog.codeship.com/continuous-integration-and-delivery-with-docker/ –

答えて

11

もちろん、これを行う方法には複数のベストプラクティスと多くのアプローチがあります。別のVCS-レポ(私たちは私の最新のプロジェクトでは二つの異なるGitのルポを使用)でのドッキングウィンドウコンテナから

  • セパレート展開可能コード(瓶/戦争など):私は成功を発見した一つのアプローチは、次のようです。つまり、コードを展開するために使用するドッカー画像は別の手順で作成されます。 A docker-buildそうです。たとえば、データベース、アプリケーションサーバー、Redisキャッシュなどのドッカーイメージを構築します。 VCSで「Dockerfile」などが変更された場合、Jenkinsなどを使用して、ドッカー画像の構築をトリガーすることができます。これらのイメージにタグを付けてレジストリにプッシュする必要があります(Docker Hubまたはローカルレジストリかもしれません)。
  • 展開可能なコード(jars/warsなど)は、Jenkinsとcommit-hooksを使用していつものように構築する必要があります。私のプロジェクトの1つでは、実際にDockerコンテナのJenkinsをdescribed hereとして実行しました。
  • ダイナミックデータを使用するすべてのドッカーコンテナ(データベースの格納場所、Tomcat/Jettyのwar-file、コードベースの構成ファイルなど)は、これらのファイルをdata volumes or as data volume containersとしてマウントする必要があります。
  • パイプラインの一部であるテストサーバーなどは、ビルドサーバーが認識している仕様に従ってセットアップする必要があります。新しく作成したタグをコードベースからドッカーコンテナのタグに接続する記述子を使用しました。 Jenkinsパイプラインプラグインは、ビルド成果物を最初にホストサーバーに移動し、ローカルレジストリから正しいドッカーイメージを取得し、その後、データボリュームコンテナを使用してすべてのプロセスを開始したスクリプトを実行できます(Figを使用してドッキングライフサイクルを管理します)。

このアプローチでは、ローカルプロセス(データベースなど)をDockerコンテナとして実行することもできました。もちろん、これらのコンテナは本番環境のものと同じイメージに基づいており、開発マシンでも開発することができます。ローカルの開発環境と本番環境の間の実際の違いだけがオペレーティングシステムでした。開発マシンは通常、Mac OS X/Boot2Dockerを実行し、Linux上で実行されました。

+1

[図](http://www.fig.sh)非推奨であり、これ以上使用すべきではありません。それは[docker-compose](https://www.docker.com/docker-compose)に置き換えられます。 – h3nrik

2

はい、jar/warファイルからビルドアーチファクトとしてイメージに移動する必要があります。 @wassgrenの記述プロセスはうまくいくはずですが、私たちのユースケースに合わせて、特に開発のために、次のことがわかりました。

1-ベースイメージを作成します。あなたがJavaのショップのように見えるので、あなたのベースイメージがFROM ubuntu:14.04のふりをして、jdkといくつかのより一般的なlibsをインストールできます。それをmyjavaとしましょう。

2開発中に、figを使用してコンテナをローカルに持ち出し、正しい場所にデベロッパーコードをマウントします。 Figはmyjavaベースイメージを使用しており、Dockerfileは気にしません。

3-デプロイメントのためにプロジェクトをビルドすると、Dockerfileが使用され、COPYのコード/ビルドアーチファクトが適切な場所に配置されます。その後、そのイメージは適切にタグ付けされ、展開されます。

2

簡単な手順を実行してください。

1)容器

2)同じ容器内のフレームワークツールをインストールでジェンキンスを取り付けます。(私はSBTを使用)。

3)gitlabのデータを統合し、すべてのjarファイルを圧縮形式(例えばbuild.tgz)にするために、必要なプラグインを使用してjenkinsでプロジェクトを作成します。

4)このbuild.tgzはどこでも動かすことができますが、トリガされますが、すべての環境依存性を満たす必要があります(例えばmysqlが必要な場合など)。

5)ここでは、基本環境イメージ(ここではmysqlがインストールされている)を作成します。

6)ビルドがトリガーされるたびに、サーバー上でドッキングファイルをトリガーしてbuild.tgzと環境イメージを結合する必要があります。

7)ここでは、環境に満足してbuild.tgzを持っています。この画像はレジストリにプッシュする必要があります。これは最終的な画像です。ポータブルでどこにでも展開できます。

8)この最終的な画像は、出力を得るために必要なマウントポイントでコンテナに保持することができ、エントリーポイントコマンドをドッカーファイルに記述することによってスクリプト(script.sh)をトリガーすることができます。

9)このscript.shはイメージ(基本イメージ)の内部にあり、私たちの目的に応じて動作するように設定されます。

10)このコンテナを持ち上げる前に、以前に実行していたコンテナを停止する必要があります。

重要事項:

画像は毎回ビルド作成され、レジストリに格納されています。 これを再利用することができます。このイメージは、メインのプロダクションサーバーにプッシュでき、トリガーできます。 これは、ベースイメージを使用しているため、毎回きれいな環境を維持するのに役立ちます。

0

また、BambooとDockerを使って安定したCDパイプラインを作成することもできます。 Bamboo Dockerインテグレーションは、エージェントフォームを構築して、アプリケーション内のバンドルされたタスクとして提供されます。あなたはこの記事が参考に見つけるかもしれない:http://blogs.atlassian.com/2015/06/docker-containers-bamboo-winning-continuous-delivery/

はあなたが別の環境で使用したり、コンテナにアプリケーションをデプロイすることができますドッカーイメージを構築するためにタスクを使用することができます。

幸運を祈る!

関連する問題