Dockerを使用して開発環境を構築する方法を素早く習得します

プラットフォームが成長し続けるにつれて、プロジェクトの研究開発は、開発者向けのさまざまな外部環境、特に基本サービスにますます依存するようになりました。これらの現象により、開発者は簡素化のために共同開発にパブリック基本コンポーネントを直接使用することがよくあります。並行開発の場合、特にデータベースやデータの変更では、他の開発者が問題のトラブルシューティングに不必要な時間を費やすことが多く、全体的な開発効率が低下し、リモート アシスタンスに大きな障害が生じます。上記の問題を解決するために、Docker Compose テクノロジを使用して開発者の開発環境の構築を支援し、最終的には開発者が Docker をインストールしていれば開発環境全体の構築を完了できるようになります。

何かを知ることとそれを達成することは全く別のことです。 Docker が誕生したその日から、私たちは「15 秒でプロジェクトをデプロイする」「バージョン管理された開発環境」、そして「ローリング開発」や「ソフトウェア定義アーキテクチャ」といった流行の運用・保守用語などを夢見てきました。波の最前線にいる業界の専門家たちは、「オーケストレーション」や「サービス検出」など、多くの用語やツールを定義、再定義し、商品化するというトレンドに、かつてないほどの熱意を持って参加しています。

このトレンドのきっかけは、Docker がアプリケーションとインフラストラクチャの間にもたらす美しいインターフェースと抽象化だと思います。開発者は基盤となるアーキテクチャを知らなくてもインフラストラクチャについて話すことができ、運用スタッフはソフトウェアのインストール方法や管理方法を理解するために多くの時間を費やす必要がありません。一見シンプルな外見の下には、人々の生活を簡素化し、効率化する何らかの力が隠されているに違いありません。

現実世界は残酷です。新しいテクノロジーを導入すれば、楽しみだけが得られると思わないでください。過去数年間、数多くのプロジェクトに携わってきましたが、奇妙な状況をいくつか経験しましたが、Docker も例外ではないと思います。しかし、特定の経験は通常、プロジェクトの次の段階に直接適用できます。 Docker の習熟度を身につけるには、実際のプロジェクトに没頭してスキルを磨く必要があります。

過去 1 年間、私は Docker の基礎に関する著書「Docker in Action」の指導に注力してきました。

Docker テクノロジーを学び始めたほぼすべての人が、エコシステム内の全員の関係を理解する前に、開発環境の作成方法に苦労していることに気づきました。誰もが、Docker を使用すると環境の設定が簡単になると考え始めますが、これはまったく間違っていません。イメージの作成やツールをコンテナにパッケージ化する方法を説明する「コンテナ化」チュートリアルは多数ありますが、開発環境を Docker 化する方法はまったく別の問題です。

先駆者として、私は自分の経験を共有することができます。

私はかつて経験豊富な Java ユーザーでしたが、ここで共有した経験は Java に関するものではなく、Go と Node を使用したアプリケーション開発に関するものです。私は Go 開発の経験があり、この分野でのスキルの向上に積極的に取り組んでいます。なじみのない分野ですぐに始める場合の主な問題は、適切なワークフローを確立することです。また、ラップトップにソフトウェアを常にインストールするのも嫌なので、これらのタスクには Docker を使用するか、場合によっては Vagrant を使用するようにしています。

私が関わっているプロジェクトは、Gin をベースにし、Redis と NSQ の特定のライブラリとサービスに依存した Go で標準の REST サービスを作成することです。つまり、ローカルで実行されている Redis および NSQ インスタンスのライブラリをいくつかインポートする必要があります。さらに興味深いのは、NGINX によって提供される静的リソースもいくつか使用していることです。

初心者のために説明すると、Go は実際に「go」と呼ばれるコマンドライン ツールを持つプログラミング言語です。依存関係の管理、コンパイル、テストケース、その他多くのタスクに使用されます。 Go プロジェクトの場合、Git と優れたエディターを除けば、残っているのはそれらに対処することだけです。しかし、まだ問題があります。ラップトップに Go をインストールしたくありません。ラップトップには Git と Docker のみをインストールしたいのです。これらの問題により、他の環境との互換性が制限され、新規参入者の参入障壁が低くなります。

このプロジェクトにはランタイム依存関係があるため、シンプルな環境定義とオーケストレーションのためにツールセットに Docker Compose を含める必要があります。 多くの人がこれに不快感を覚えるでしょうが、私たちはどうすればいいのでしょうか? Dockerfile または docker-compose.yml の作成を開始しますか?さて、まずどうやってそれをやったかをお話しして、それからなぜそれをやったのか説明しましょう。

たとえば、www.sangpi.com の場合、ローカル パッケージを完全に自動化する必要があります。手動で手順を実行するのは好きではないので、私の vim 設定ファイルは非常にシンプルです。実行環境を「実行するかどうか」のレベルで制御したいだけです。ローカライズされた開発環境ターゲットは、生産性向上のためだけでなく、Docker イメージの共有のためにも迅速に複製されます。 Go、Node、そして私が最もよく使用するパッケージング ツール Gulp を含むイメージを生成する Dockerfile がようやく完成しました。 この Dockerfile には埋め込みコードがなく、イメージには埋め込まれた Gulpfile がありません。代わりに、ボリュームは確立された GOPATH (Go ワークスペースのルート) 上に定義されます。

最後に、これらの画像を提供するための gulp のエントリポイントを設定し、デフォルトのコマンドを monitor に設定しました。出力イメージは、ビルド アーティファクトと呼ぶものではありません。この意味で、この環境が行う唯一のことは、コードが実行されているかどうかを判断するのに役立つ実行中のインスタンスを提供することです。私のシナリオでは、それはうまく機能します。別のビルドを参照するには、「アーティファクト」を使用します。

次に、Compose を使用してローカル開発環境を定義します。まず、イメージで使用される Docker Hub で定義されているすべての依存サービスを定義し、それらを「ターゲット」サービスに接続します。このサービスは、新しい Dockerfile が生成された場所を参照し、新しいイメージが出力されるマウント ポイントにローカル ソース ディレクトリをバインド マウントし、テストできるいくつかのポートを公開します。次に、ターゲット サービスに対する一連の統合テストを継続的にループするサービスが追加されました。最後に、NGINX サービスを追加し、多くの構成ファイルと静的アセットを含むボリュームをマウントしました。ボリュームを使用する利点は、イメージを再構築せずに構成ファイルとアセットを再利用できることです。

すべてのコードは最終的にコンピューター上にローカル開発環境を生成します。使用する場合:

docker-compose を起動します –d

git clone が開始され、ループで実行されます。イメージを再構築したり、コンテナを再起動したりする必要はありません。 .go ファイルが変更されるたびに、Gulp は実行中のコンテナーでサービスを再構築して再起動します。とても簡単です。

この環境を作るのは簡単ですか？実際はそうではないのですが、それは起こりました。コンテナを使用せずに、Go、Node、Gulp をローカルにインストールする方が簡単ではないでしょうか?このシナリオでは可能かもしれませんが、この依存サービスを Docker で実行することに制限されます。これは好きじゃない。

以前は、これらのツールのさまざまなバージョンを管理する必要があり、その結果、複雑な環境変数と成果物があらゆる場所で生成されていました。集中型バージョン管理がないため、競合が発生しやすい環境変数について同僚に注意喚起する必要がありました。

おそらく、上記の環境が気に入らないか、プロジェクトに別のニーズがあるのでしょう。そうですね。この記事は、すべてのツールを Docker で実行することに関するものではありません。もしそうであれば、私たちが解決しようとしている問題が何なのかを検討していないことになります。

この環境を設計する際に、私は以下の質問、懸念事項、およびいくつかの潜在的な答えを考慮しました。 Docker を使い始めると、実際の状況が答えよりも悪い場合があることに気付くかもしれません。

包装と環境について考えるとき、まず何を考慮しますか?

これは確かに最も重要な質問です。このシナリオにはいくつかのオプションがあります。 Go を使用してコンテナ内で直接プログラムすることができます。次のようになります。

実際、この例のボイラープレートのほとんどは、シェル エイリアスまたは関数を通じて非表示にできるため、Go が独自のデバイスにインストールされているように感じられます。また、Go ワークフローに接続してアーティファクトを作成することもできます。これらの機能は非サーバー プロジェクトには有益ですが、ライブラリ プロジェクトやソフトウェア プロジェクトには必ずしも有益ではありません。

すでに Gulp、make、ant、またはその他のスクリプトを使用している場合は、それらのツールのターゲットとして Docker を使用できます。

あるいは、Dockerbuild を使用してビルドを定義および制御することで、より Docker 指向のエクスペリエンスを得ることができます。コードは次のとおりです。

Docker を使用してビルドを制御することにはいくつかの利点があります。以前にコンパイルされたイメージを使用することができ、Dockerfilebuilds はキャッシュ アプローチを使用するため、コンパイル作業では最小限の手順のみが繰り返されます (優れた Dockerfile があることを前提とします)。最後に、これらのビルドによって生成されたイメージは他の開発者と共有することもできます。

この場合、golang リポジトリの onbuildimage をベースとして使用します。これには、依存関係をダウンロードするための優れたロジックが含まれています。この方法により、他の非本番環境で簡単に使用できる Docker イメージが生成されます。実稼働レベルのイメージに対するこのアプローチの問題は、サービスを開始して監視する前に、大きなイメージを避け、ステータスを確認するためのいくつかの init スクリプトを組み込むための手順を実行する必要があることです。

興味深いことに、Docker は一連のスクリプト、Makefile、Dockerfile を使用します。ビルド システムは比較的堅牢で、さまざまなゲーム テスト、リンティングなどのほか、さまざまなオペレーティング システムやアーキテクチャの成果物も処理します。このシナリオでは、コンテナーはバイナリを生成するために使用されるツールですが、ローカル ビルド イメージから実装されます。

Docker ビルドのオプションを拡張するには、Compose を使用して完全な開発環境を定義できます。

Compose は環境管理を担当します。システムが非常にクリーンであることは驚くことではありません。Compose はすべてを結び付け、ボリューム管理を最適化し、イメージが不足している場合は自動的にイメージを構築し、ログ出力を集約します。これらのスイッチを選択したのは、サービスの依存関係を簡素化するためと、必要な成果物を生成するためです。

この例はランタイム コンテナーであり、Compose または Docker にはこれに適したツールがあります。このシナリオでは、分散イメージが必要になる場合や、ビルドでローカル マシン用のバイナリ ファイルを生成する必要がある場合があります。

目的のイメージを取得するには、ビルド中にソース コードまたはプリコンパイルされたライブラリがイメージに埋め込まれていることを確認する必要があります。ビルド中はボリュームはマウントされないため、繰り返すたびにイメージを再構築する必要があります。

コンテナ内に特定の成果物を生成する場合は、マウントされたボリュームを導入する必要があります。これは、Docker コマンドラインまたは Compose 環境を使用して簡単に実行できます。ただし、コンテナが実行されていないとビルドは機能しないため、docker build だけを使用することはできないことに注意してください。

まとめ

現在、開発環境を作成するための Docker の方法はありません。 Docker は単なる聖書ではなく、オーケストレーション ツールです。他の人の既存の dockerbuild システムを使用するのではなく、時間をかけてこのツールを学習し、ニーズを明確にしてから、自分に合った Docker 環境を作成することをお勧めします。

Docker を使って開発環境を構築する方法を素早くマスターする方法についての記事はこれで終わりです。Docker を使った開発環境の構築に関するより関連性の高いコンテンツについては、123WORDPRESS.COM の過去の記事を検索するか、以下の関連記事を引き続き閲覧してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。