docker-composeがない場合

議論されること

ここでは、作成者がdockerを使用するアプローチを共有している投稿が定期的に表示されます。 さて、ここにあなたのための別のものがあります。 以下に、Docker環境での経験、遭遇した不便さ、それらとの闘い、およびその結果について説明します。 また、小さいながらも非常に便利なツールを共有します。

以前の生活

まず、少し歴史。 そのため、私たちは勤務中に、ある程度、同時に複数のプロジェクトを開発およびサポートしています。 それらはすべて、年齢、要件が異なるため、異なる環境で動作します。 この点で、ローカルコピーを展開するときに不便がありました。 以前に作業したことがないプロジェクトに切り替えるときは、作業環境を設定するだけでなく、それを設定する必要があります。 チーム内でこれを非常に迅速に解決できる場合、定期的に接続されているフリーランスの開発者ではますます複雑になります。 開発をdocker環境に移行することが決定されました。 ここでは何も発明しませんでしたが、一般に受け入れられた道を進みました。 各サービスは別々のコンテナに入れられました。 バンドルには、docker-composeを使用しました。

複数のプロジェクトの並行作業を行うには、各プロジェクトに必要なすべてのサービスのインストールが必要です。 まず、Docker-composeの構成ファイルが置かれているリポジトリーと、操作に必要なイメージの構成を作成しました。 すべてが非常に迅速に機能し、しばらくの間私たちに適していました。 判明したように、将来、このアプローチは問題を部分的に解決しました。 新しいエコシステムにプロジェクトが追加されると、このリポジトリには構成ファイルとさまざまなサポートスクリプトがいっぱいになりました。 これにより、1つのプロジェクトで作業する場合、開発者はすべてのプロジェクトの依存関係をドラッグするか、docker-compose.ymlを編集して不要なサービスを無効にする必要がありました。 最初のケースでは、余分なコンテナを配置する必要がありましたが、これは最善のソリューションではないと思われましたが、2番目のケースでは、アプリケーションが機能するために必要なコンテナを知る必要がありました。 必要なコンポーネントのみをインストールでき、除外しない場合は手作業を最小限に抑えることができる、より柔軟なソリューションが必要でした。 そして、これは私たちが来たものです...

ddk

ddk（Docker Development Kit）は、環境のセットアップを簡素化し、Docker環境で実行されるプロジェクトの開発環境の展開を自動化するように設計されたツールです。 おそらくたくさん聞こえます。 実際、ddkはgitとdockerの一種のラッパーであり、パッケージ、構成ファイル、プロジェクトを便利に管理するための追加のコマンドを多数提供します。 ある意味では、これはプロジェクトおよびサービス用のdocker-compose環境依存関係マネージャーです。

最初、ddkはpythonスクリプトのセットですが、エンドユーザーは、使用する実行可能ファイルのみを受け取ります。 ここで、docker自体とdocker-composeのインストールに加えて、開発者は構成ファイルを作成してddkを初期化する必要があります。 このタスクは、initコマンドを呼び出すことで実行されます。

cd /var/projects/ddk ddk init 

その後、新しいプロジェクトへの接続は次のとおりです。

 ddk project get my.project.ru ddk compose --up 

また、必要に応じて、新しいドメインをローカルホストにリダイレクトします。

 echo 127.0.0.1 my.project.ddk >> /etc/hosts 

最初のコマンドはプロジェクトを複製し、初期化します。 2番目は、docker-composeの構成を生成し、必要なサービスを開始します。 実行中に、不足しているすべてのコンポーネントがロードされます。 アセンブリが完了すると、開発者はプロジェクトの完全に機能するローカルコピーを受け取ります。これはmy.project.ddkで入手できます。

仕組みについて少し説明します。

ddkを使用する場合、作業ディレクトリは、initコマンドによって生成された構成ファイルが置かれているディレクトリです。 実行可能ファイル自体は、便利な場所に配置できます。 構成は現在のディレクトリから検索され、ddkは検索対象のファイルを見つけるか、ファイルシステムのルートに到達するまでディレクトリツリーを上に移動します。 Gitとdocker-composeは同様に機能します。 構成ファイルが見つかると、ddkはプロジェクトのパッケージとソースコードを保存するためのディレクトリを作成し、依存関係を解決してインストールします。 コンポーネントは、gitリポジトリのクローンを作成するだけでインストールされます。gitリポジトリのアドレスは、構成ファイルのコンポーネント名とプレフィックスを連結することで決定されます。

 # "project-repo-prefix": ["git@github.com/vendor-name/"] ddk project get my.project.ru git clone git@github.com/vendor-name/my.project.ru.git 

もちろん、ddkはgit cloneの単純なショートカットではなく、追加機能があります。 方法、理由、理由について-少し低め、ここでは、結果としてすべてのプロジェクトが収集されるディレクトリと、その作業に必要な構成ファイルのみが追加されることを追加します。 このディレクトリは、別のディレクトリまたは別のマシンに簡単に移動できます。

ddkパッケージ

私が最初に達成したかったのは、環境全体を可能な限りモジュール化することでした。 個別の構成ファイルで各サービスの説明を強調し、それらを独立したリポジトリに移動しました。 同僚はそれらをパッケージと呼びました。 これらのまさにパッケージが私たちのツールの基礎を形成しました。 docker-compose.ymlをビルドすると、ddkは必要なすべてのパッケージを反復処理し、それらに基づいて最終的な構成ファイルを生成します。

原則として、アセンブリ中に不足しているコンポーネントがすべて自動的にロードされるため、個々のパッケージを自分でインストールする必要はありません。 それでも、それらをインストールおよび更新することは可能です。

 ddk package install package-name ddk package update 

次にコンテンツについて。 ルートは常にddk.json設定ファイルであり、コンテナの名前と使用されているdockerイメージを示します。 以下は、最小構成のパッケージの例です。

 { "container_name": "memcached.ddk", "image": "memcached:latest" } 

お気づきかもしれませんが、実際、これは、JSON形式で表示されるdocker-compose.ymlの構成の一部です。 このアプローチにより、docker-composeがサポートするパラメーターを設定できます。 個別のDockerfileを使用してディレクトリをマウントする、より複雑なパッケージの例を次に示します。

 { "build": "${PACKAGE_PATH}", "container_name": "nginx.ddk", "volumes": [ "${SHARE_PATH}/var/www:/var/www", "${PACKAGE_PATH}/storage/etc/nginx/conf.d:/etc/nginx/conf.d:ro", "${PACKAGE_PATH}/storage/etc/nginx/nginx.conf:/etc/nginx/nginx.conf:ro", "${PACKAGE_PATH}/storage/var/log/nginx:/var/log/nginx" ] } 

パッケージディレクトリのリスト：

 storage/ etc/ nginx/ conf.d/ site.ddk.sample nginx.conf ddk.json Dockerfile 

「ddk-」で始まるキーは、特別なディレクティブを指定するために使用されます。 現時点でサポートされている唯一のキーは「ddk-post-install」で、パッケージのインストールおよび更新後に実行されるコマンドのリストが保存されます。

 { "ddk-post-install": [ "echo 'Done'" ] } 

このオプションを使用するためのオプションの1つは、「契約」セクションに記載されています。

プロジェクト

次に、特定のプロジェクトの例でddkを使用する方法を検討します。 既存のプロジェクトをデプロイするには、 getコマンドを呼び出すだけです。

 ddk project get project-id 

このコマンドは、プロジェクトをshare / var / wwwディレクトリーに複製し、その後、構成ファイルが検索され（デフォルトではプロジェクトのルートで）、on-initセクションから必要なすべてのコマンドが起動されます。 この段階で、個々のプロジェクトパラメーターが構成されます（.envの生成、ファイルのアクセス許可の設定、データベースの構成など）。

初期化コマンドに加えて、ddk.jsonファイルには、プロジェクトの操作が依存するパッケージのリストが含まれています。 パッケージの1つが欠落している場合、自動的にインストールされます。 以下はプロジェクト構成の例です。

 { "packages": [ "mysql5.5", "memcached", "apache-php5.5" ], "on-init": [ "${PROJECT_PATH}/init.sh ${PACKAGES_PATH} ${PROJECT_DIR}" ] } 

on-initセクションでは複数のコマンドを転送できますが、通常は1つだけを指定します。 上記の例では、プロジェクトが初期化されると、メインの構成を実行する展開スクリプトが起動されることがわかります。 このアプローチは、柔軟性が高く、プロジェクトの初期化プロセスに対話性を追加できるため、より便利であることが判明しました。

パッケージの構成を拡張する必要がある場合は、パッケージをオブジェクトとして指定することでこれを行うことができます。 このオブジェクトには、パッケージの名前を含む名前属性が必要です。 他のすべての属性は構成として認識されます。

 { "packages": [ { "name": "nginx", "depends_on": [ "php-fpm7.1" ], "environment": [ "SOME_VAR=Hello" ] } ] } 

したがって、パッケージの元の構成を変更することなく、サービスの動作に影響を与えることができます。

合意

Docker環境での作業の過程で、私たちはいくつかの規約を作成しました。

まず、パッケージまたはプロジェクトのファイルとディレクトリをマウントするとき、それらの構造はコンテナ内の構造と一致する必要があります。 つまり package-name / storageは、package-nameコンテナのルートディレクトリと一致します。 共有ディレクトリは、コンテナのルートディレクトリとも一致します。 これが、すべてのプロジェクトがshare / var / wwwにある理由です。 このルールは、上記の例でも追跡されています。

次の項目は、ファイルシステムが変更されることになっているコンテナにパッケージをインストールするときに、特別なユーザーが作成され、その資格情報がホストシステムユーザーのデータに対応することです。 つまり、ホストシステムからコンテナにログイン、ユーザーID、およびグループIDをマッピングします。 将来、このデータを使用してコンテナ内のすべてのコマンドを実行することをお勧めします。 このアプローチにより、コンテナ外部のファイルにアクセスする際のアクセス権の問題を回避できます。 少なくとも1つのプロジェクトがこのように構成されている場合、share / home / <user-dir>ディレクトリが作成され、コンテナにマウントされてホームディレクトリとして使用されます。 以下は、これをどのように実装したかの例です。

 { "container_name": "php71-fpm.ddk", "command": "map-user.sh", "env_file": [ "${PACKAGE_PATH}/env/user.env" ], "ddk-post-install": [ "mkdir -p ${PACKAGE_PATH}/env", "echo USER_NAME=`whoami` > ${PACKAGE_PATH}/env/user.env", "echo USER_ID=`id -u` >> ${PACKAGE_PATH}/env/user.env", "echo GROUP_ID=`id -g` >> ${PACKAGE_PATH}/env/user.env" ] } 

ご覧のとおり、パッケージをインストールすると、ユーザーデータを含むファイルが生成されます。 コンテナが起動すると、map-user.shスクリプトがチェックし、必要に応じて、受信したデータを使用してアカウントを作成します。

魔法のピンチ

最後に行う必要があるのは、通常のdocker-composeを使用して必要なすべてのサービスを開始することです。 起動パラメーターを生成するには、composeコマンドを使用します。 呼び出されると、ddkはすべてのアクティブなプロジェクトを通過し、パッケージとそのパラメーターに関するデータを収集し、受け取ったすべての情報をパッケージ自体の構成と組み合わせ、これらのデータに基づいて最終的なdocker-compose.ymlを生成します。 このファイルは起動時に使用されます。

 ddk compose docker-compose up -d 

構成の構成時に適切なオプションを指定すると、1つのコマンドで実行できます。

 ddk compose --up 

ハローワールド

ddkの動作を確認したい人は、デモプロジェクトを展開できます。

最新のビルドをダウンロードします。

 wget https://github.com/simbigo/ddk/raw/master/dist/ddk chmod +x ddk 

将来のドメインを構成します。

 echo 127.0.0.1 hello.ddk >> /etc/hosts 

プロジェクトを展開します。

 ./ddk init ./ddk project get hello ./ddk compose --up 

すべての画像を正常に組み立てた後、プロジェクトはhttp：//hello.ddkで利用できます。

おわりに

達成したこと：

1. モジュラー環境。
2. 1つのコマンドによる構成の形成。
3. 再利用可能な手作りの欠如。
4. プロジェクトに開発者を含める最小時間。

取り組む価値のあるもの：

1. ddkにはエラー処理はほとんどありません。
2. 彼らはMacOSで正しい操作を実装することを計画していましたが、現時点では、チームにはマクロドライブがなく、ツールはこのシステムでテストされていません。 ほとんどの場合、いくつかの機能が登場し、修正が必要になります。
3. パッケージおよびプロジェクトのリポジトリアドレスは配列として転送されますが、実際には、作業は最初の要素でのみ実行されます。 リポジトリの存在の正しい検証を実装し、複数のアドレスを検索する必要があります。
4. 余分な容器の除去。
5. 初期化スクリプトには多くの反復コードがあります。 たぶん、ddkで一般的な機能を使用するのが理にかなっています。

コードを表示、改善、または単に批判したいだけのユーザーのために、githubへのリンクを添付しています。 このツールが私たち以外の誰かにとって有用であれば、私たちは喜んでいます。

githubにアクセス