Clever Geek Handbook

DockerベースのWeb開発環境の作成

猫の下で、 Docker 、 Fig 、 DNSMasq 、 nsenterに基づいたWeb開発環境の自動作成と展開をどのように改善したかを説明します。 実際、これはLAMPサーバーの展開であり、DNSMasqに記録しますが、優先順位は、ホストマシン上のWebサーバー、DBサーバー、実行するコマンドの最小数などの不要なソフトウェアでホストマシンが詰まらないことです。



まえがき



前回の記事http://habrahabr.ru/post/236573/で、 VirtualBoxに基づいたWeb開発用のクイックデプロイメント環境を整理する方法について話しましたが、同時に、経験豊富なhabrausersからDockerに目を向けるよう勧められました。 その後、その男を開いて実験を開始し、 PHPの異なるバージョン（ 5.3、5.4、5.5 ）の3つのコンテナーを自分で収集しました。 将来的には、ブートストラップスクリプトをより健全な言語で書き直し、なんとかしてこれをすべて整理し、男を書きたいという要望がありました。 しかし、いつものように、手はこれに届かず、クリスマスイブにドッカーのホームディレクトリを誤って削除してしまった場合は、おそらく到達しなかったでしょう。 はい、そうです。 最終的に、すべてが書き直され、再編成され、 GitHubにアップロードされました 。



何が必要ですか？



  1. Docker.IO（ https://www.docker.com/ ）
  2. fig（ http://www.fig.sh ）
  3. DNSMasq（ http://www.thekelleys.org.uk/dnsmasq/doc.html ）
  4. nsenter（ https://github.com/jpetazzo/nsenter ）




何が起こっているの？



fig



を使用してスクリプトから起動すると、必要なすべてのコンテナーが展開され、リンクされます。 その後、データベースダンプのあるファイルが指定されている場合、ダンプはコンテナ内に作成されたデータベースに注がれます。 次に、コンテナエントリがDNSMasq構成に追加され、デーモンが再起動します。

スクリプトを使用してシャットダウンすると、データベースがファイルにダンプされ、 DNSMasq構成からのレコードが削除され、デーモンが再起動します。



設定方法は？



必要な最小DNSMasq構成： 

 # cat /etc/dnsmasq.conf | grep -E -v '^(#.*)?$' listen-address=127.0.0.1


これらすべてが機能する.efig



に、 https：//github.com/dvapelnik/efigリポジトリのクローンを作成し、そこにある.efig



フォルダーを探します。これをプロジェクトフォルダーに配置します。 このフォルダにはすでに次のものがあります。

  1. logs



    -Webサーバーログのディレクトリ
  2. xd_profile



    、 xd_trace



    -XDebugファイル用の2つのディレクトリ
  3. db



    展開とバックアップ用の2つのスクリプトを使用してデータベースを操作するためのディレクトリ
  4. efig.yml



    -figの構成
  5. efig.conf



    -efig自体の構成
  6. httpd.conf



    -apache2 config
  7. efig.sh



    するefigスクリプト自体


efig.yml



、データベース名、データベースのユーザー名、およびパスワードを指定する必要があります。 必要に応じて、テスト用のデータベース。 データベースを正しくデプロイしてダンプバックするには、データベースの名前がダンプ付きファイルにどのように関連付けられているかを示す必要があります。

E_DB_DUMP



メインデータベースのファイル名
E_DB_NAME



メインデータベース名
E_DB_TEST_DUMP



テストデータベースファイル名
E_DB_TEST_NAME



テストデータベース名


テストデータベースが不要な場合は、最後の2行でコメントし、テストデータベースの名前を変数DB_NAME



から削除できます。 ダンプのあるファイルは、 db



フォルダーに関連して検索されます。

アプリケーション用にhttpd.conf



構成します。

次の値がefig.conf



指定されていefig.conf





PROJECT_NAME



プロジェクト名（ URLで使用されます ）
FIG_CONF



fig



設定名
SUBDOMAINS_ENABLED



各コンテナにサブドメインを作成するかどうか
DNS_ZONE



プロジェクトのDNSゾーン、元は.doc



使用
MAIN_CONTAINER_NAME



メインコンテナの名前、最初はweb



（ fig



configから取得）
DB_CONTAINER_NAME



DBコンテナの名前、最初はdb



（ fig



configから取得）
DNSMASQ_CONFIG_PATH



DNSMasq構成へのパス


SUBDOMAINS_ENABLEDの補足
たとえば、データベースコンテナにアクセスするには、ドメイン名（たとえば、 http：//db.myproject.doc/を使用します。IPではなく、起動するたびに常に変更されます）。





そして今 これらすべての設定、フォルダー、およびスクリプトを使用して、離陸しようとします 走ってみる



離陸するには、 .efig



フォルダーに移動し、 sudo



介してスクリプトを実行する必要があります。 

 sudo ./efig.sh


この時点で、コンテナが起動され、データベースが/etc/dnsmasq.conf



新しいコンテナに関するエントリが/etc/dnsmasq.conf



に追加され、デーモンが再起動します。 その後、ブラウザhttp：//project.doc/のリンクを安全にたどり、すでにブラウザにあるプロジェクトを確認できます。

コンテナーを無効化して削除し、データベースをバックアップするには、同じフォルダー（ .efig



）で次のように書き込みます。 

 sudo ./efig.sh rm


データベースはファイルにダンプされ、コンテナは停止して削除されます。すべてが意図したとおりにクリーンです。



コンテナにはどのイメージを使用する必要がありますか？



Webコンテナーとして、均一に構成されたイメージを使用することをお勧めします（以前のバージョンのPHP （ 5.3、5.4、5.5、5.6 ）を備えたDebian / Ubuntuに基づくイメージはDockerHubで入手できます）。 PHPのパッケージは、必要なYiiFramework（1、2）を考慮して選択されました。必要に応じて、開発に必要な他のパッケージを追加できます。 dbコンテナーとして、sameersbnのイメージを使用します。



そして練習する？



たとえば、同じJoomla CMSをデプロイしようとすることができます（最初にCMSとして発生しました。これはデプロイが簡単で、データベース自体を生成します）。

  1. efig



    からefig



    する
  2. Joomla CMSアーカイブを取得する
  3. 開梱
  4. Joomla CMSを .efig



    して.efig



    をフォルダーにコピーします
  5. .efig/efig.yml



    データベースのパラメーターを指定します
  6. このビジネスを開始しますcd .efig/ && sudo bash ./efig.sh



  7. 人生を楽しむ 見る/設置する
  8. cd .efig/ && sudo bash ./efig.sh rm







過去、現在、未来？



少なくとも、起動する場合のみ、アプリケーションの展開を簡素化するために、これは自分用に書かれています。 誰にもわからないが、どこかに新しいサブドメインを作成してそこにファイルをアップロードしたり、別のプロジェクトにサブフォルダーを使用したりするのは面倒だ。 さらに、 PHPの 4つのバージョンすべてが必要でした。 要求と私のニーズとして、私はすでにそこにあるものを終了します。 PostgreSQLのサポートを台無しにするつもりですが、まだ自分で使用していないので、 台無しにしませんでした。 スクリプトはUbuntu OSで実行されましたが、他のLinuxディストリビューションに問題があるとは思いません。 他の配布の確認はできませんでした。



リンク？



  1. GitHubのプロジェクトリポジトリ： https : //github.com/dvapelnik/efig
  2. GitHub上のDockerのイメージリポジトリ： https : //github.com/dvapelnik/docker-lap
  3. DockerHub上のDockerの イメージリポジトリ： https : //registry.hub.docker.com/u/dvapelnik/docker-lap/




落とし穴？



  1. データベースダンプがなく、データベースがそれ自体で生成された場合（移行、 Joomla CSMなどのデプロイメントなど）、コンテナーが切断されると、データベースはダンプされますが、 rootとしてダンプされます。 これは、コンテナでは、ダンプが実際にはコンテナルートの下にあるためです。 開始する前に、シャットダウン時にデータベースがダンプされる空のファイルを作成できます-これはそのような回避策です。 Webコンテナーでの同様の状況。 コンテナにフォルダをマウントすると、コンテナから作成されるすべてのファイルがルートによって作成されます。 使用した回避策について説明します。ユーザーとしてUIDとGIDを持つロバユーザーがコンテナ内に作成され、その下で開発を行います。 ユーザーのUIDとGIDが1000と異なる場合は、対応するDockerfileを取得して、ユーザーのUIDとGIDをそこに置き換えて、イメージを再構築する必要があります。 e-データベースイメージの場合、これは特に重要ではありませんが、ダンプするときは横向きにクロールします。 そんな松葉杖だから。
  2. 合理的な疑問が生じます。コンテナ内のデータベースにアクセスする方法は？ すべてのSUBDOMAINS_ENABLED



    コンテナのドメイン名を作成するオプションを作成したのは論理的であり、そのためだけです。 フラグが1



    に設定されている場合、すべてのコンテナに対して、フォームのDNSMasq構成に記録することによって作成されます CONTAINER_NAME.PROJECT_NAME.DNS_ZONE



    CONTAINER_NAME.PROJECT_NAME.DNS_ZONE



    コンテナは、データベースにアクセスするためのポートを吐き出し、このドメイン、ポート、およびefig.conf



    に登録されたユーザーデータを使用してアクセスできます。


More articles:


All Articles