X時間とY日間のDockerの基本

0.はじめに

この記事の目的は、日常的にドッカーの操作を開始し、ローカルにインストールされたapache、mysql、virtualenv、python3、mongodb、memchaced、redis、php5、php7および残りを作業マシンから削除するために最低限必要な基本情報を小さなヒープに収集することです開発中に使用し、バージョン間で競合することも多い動物園。



そして、私はバスに乗っており、次の7時間はまだ何もしません。 さて、さらに、私は最終的にリンクとコマンドを1か所に集めます。このリンクとコマンドは、定期的にドキュメントにアクセスする必要があります。たとえば、ケシのローカルホストにIPエイリアスを追加する方法： sudo ifconfig lo0 alias 10.200.10.1/24



（なぜ必要なのか）後で言った）



この記事はそれが呼ばれる方法と呼ばれます。タスクに必要な時間を多少正確に計算できなかったからです。 3日間で約6時間かかりました。 主に、その瞬間、私はオフィスでフルタイムで働いており、いわば、生産を中断することなく、ドッカーを習得したからです。



徹底的に掘り下げる度合いに応じて、数日または数時間かかります。



しかし、私の個人的な意見では、1日で「侵入」しようとしない方が良いと考えています。 あなたがこれに対処したことがないなら、最初の日の終わりにあなたはどこかにそのような頭を持っているからです









そして、現時点では、停止し、情報を消化し、場合によってはスリープ状態にすることをお勧めします。

1.理論

以前にvirtualbox、vmware、vagrantなどの仮想マシンとツールを扱ったことがある場合は、それらを忘れてください。

個人的に、私の間違いは、仮想マシンとしてdockerを使用しようとしていました。 Dockerは、システムではなくプロセスを仮想化する手段です。 重要なルールは、各プロセスに独自の仮想コンテナがあることです。



コンテナは別のプロセスとして理解されるべきであり、その逆も同様です。 たとえば、mysqlとredisを同じコンテナに押し込むことはできません。 さらに悪いことに、Apache + php + mysqlの束全体。

主な用語

イメージ -プロセスをイメージに保存するために必要な組み立てられたサブシステム。

コンテナは、イメージに基づいて初期化されるプロセスです。 つまり、コンテナは実行中にのみ存在します。 それはクラスのインスタンスのようなもので、画像はクラス型です。 まあ、私は考えが明確だと思います。

ホスト -ドッカーが起動される環境。 簡単に言えば、ローカルマシンです。

ボリュームは、ホストとコンテナの間のディスク容量です。 より簡単なのは、コンテナ内にマウントされたローカルマシン上のフォルダです。 ここでの変化はそこでの変化であり、その逆もまた奇跡です。

Dockerfile-将来のコンテナーのイメージを作成するための一連の指示を含むファイル

サービス（サービス） -実際には、これは実行中のイメージ（1つまたは複数のコンテナー）であり、さらにポートを開く、フォルダー（ボリューム）をマッピングするなどのオプションによって構成されます。 これは通常docker-compose.ymlファイルを使用して行われます。

Docker-compose （docker-composer、より多くの場合はcomposer、しかしphp composerと混同しないでください）は、相互接続された複数のコンテナで構成されるシステムの組み立てと起動を容易にするツールです。

ビルド（ビルド、ビルド） -コンポーザーを使用してビルドを行う場合、dockerファイルまたはいくつかのdockerファイル内の一連の命令からイメージを作成するプロセス

この記事の後半（明日）では、dockerfileとdocker-composeファイルの例と説明を使用して、nginx + mysql + php7-fpmの束を組み立てるプロセスについて説明します。

イメージ構築の仕組みについて簡単に

まず、ドッカーハブがあります。これは、自分自身を表明したいすべての人が独自のイメージビルドを公開するようなリポジトリです。 他のパッケージのダンプと同じように、これには感謝しますが、感謝しません。



通常、dockerfileはFROM命令で始まります。これは、ハブからのどのパッケージ/イメージを開始するかを示します。



以下は通常メンテナーの指示であり、そのタスクは次の素晴らしい創造物の創造者の名前を永続させることです。



次に、最も一般的なコマンドは次のとおりです。

RUN-イメージ内でコマンドを実行します。

ADD-ホストからファイルを取得し 、イメージ内に配置します。

COPY、EXPOSE、ENTRYPOINT、CMDと同様に、このすべてをプロセスで学習します。



今注目します。 Dockerは、前の結果に加えて、dockerファイルからの命令を順番に実行します。 このようにして、キャッシュストレージが編成されます。

分かりませんか？ 今からお見せします。 最も簡単なdockerfileは次のとおりです。

 FROM ubuntu:latest MAINTAINER igor RUN apt-get update RUN apt-get install nginx ADD ./nginx.conf /etc/nginx/ EXPOSE 80 CMD [nginx]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ドッカーがビルドするとき：



1.最新のタグでubuntuイメージをダウンロードし、ID = aaaで保存します

2. aaaイメージを取得し、maintainer = igorを指定し、ID = aabで保存します

3. aabイメージを取得し、コンテナーを起動して、内部で「apt-get update」コマンドを実行し、コンテナーを停止し、ID = aacで結果のイメージを保存します

4. aacイメージを取得し、コンテナーを起動して、内部で「apt-get install nginx」コマンドを実行し、コンテナーを停止し、結果のイメージをID = aadで保存します

5. aadイメージを取得し、コンテナーを開始し、パス/ etc / nginx /に沿ってコンテナー内の./nginx.confファイル（パスはdockerfileがあるフォルダーに相対的です）をコピーし、コンテナーを停止し、ID = aaeで結果のイメージを保存します

...



もう理解できる？



ここで条件付きIDを記述しましたが、これらの「中間」イメージの識別子は、ADDステートメントによって追加されたファイルと親イメージのIDによって、命令自体に直接関連していることを覚えておくことが重要です。 つまり、各ステップが完了する前に、イメージのID（ハッシュ）が最初に計算され、ローカルキャッシュでそのようなIDを検索し、キャッシュにそのようなIDがない場合にのみ、ステップが実行されてキャッシュに保存されます。それ以外の場合は、キャッシュからのイメージが使用されます



また、これは、たとえばrun apt-get install nginx



を別のコマンドにrun apt-get install nginx



するなど、コマンドを変更することにした場合、命令のハッシュ（ID）が変更され、その後のすべてのキャッシュは使用されないことを意味します。 したがって、メンテナーの名前の1文字を変更した後、アセンブリ全体が最初から再構築されても驚くことはありません。



また、コマンドを実行するための記述されたスクリプトに基づいて、実行後に何も保存しないコマンドを実行する命令で意味をなさない理由が明らかになります-スタックオーバーフローに関するよくある質問は、「何かを開始しましたが、次の命令で実行されていません」です。 たとえば、誰かがソースenv / bin / activateをアクティブ化し、次の指示でpip installを実行したい場合

 RUN source /app/env/bin/activate RUN pip install something
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または別の例-Mongodbを実行し、次の指示でユーザー/データベースを作成するか、ファイルからデータベースをインポートします（これを行わない方が良い理由がありますが、今はそれについてではありません）



RUN service mongodb start

RUN mongo db --eval 'db.createUser({user:"dbuser",pwd:"dbpass",roles:["readWrite","dbAdmin"]})'







アセンブリプロセスからわかるように、次の各コンテナは前のステップでそこに起動されたものについて何も知らないため、これらの指示は&&を介して1つにまとめる必要があります。



RUN source /app/env/bin/activate \

&& pip install something



RUN service mongodb start \

&& RUN mongo db --eval 'db.createUser({user:"",...})'







しかし一般的に、コンテナが隔離されているという事実のため、nvm、virtualenv、rbenvなどのツールを内部で使用することにあまり意味はありません。 必要なものを入れるだけです。



この理論は作業を始めるのに十分だと思います。

2.練習

始める前に、休憩を取り、自分をカモメにするべきだと思います。

戻ってきたら、まずDockerとDocker Composeをインストールします。



Windowsでこれを読む人のための小さな余談。



本気ですか？



いいえ、もちろんこれは可能です。サイトにはインストールファイルと手順があります。 個人的には、メディアステーションとしての家庭での使用に関して、私は窓に対して何もしていません。 しかし、Windowsで開発する場合は、同時に私はあなたと哀ireの意を称賛します。 率直に言って、私自身はWindowsの下でdockerを上げず、ubuntuとケシの下だけでした。 しかし、次のオフィスの同僚のうめき声を聞き、彼はなんとかアセンブリを開始することさえできましたが、ボリューム内のシンボリックリンクに関しては、すべてが無駄になりました。 したがって、WindowsでDockerを使用する方法に関するレシピを求めてここに来た場合、悪いニュースがあります。ここでは見つかりません。



そのため、この段階では、既にドッカーがインストールされており、タスクバーに＃ブルーキットブロックでうれしそうにバブルします（申し訳ありませんが、抵抗できませんでした）。 次に、このリンクをたどって、Get Startedチュートリアルを実行します。



ここで、PHPでWebサイトを開発しており、nginx + php7-fpm + mysqlリンクを使用して公開することを想像してみましょう。



phpサービス用の非常に原始的なdockerfileを次に示します。



FROM php:7-fpm

# Install modules

RUN apt-get update && apt-get install -y \

libfreetype6-dev \

libjpeg62-turbo-dev \

libmcrypt-dev \

libpng12-dev \

libicu-dev \

--no-install-recommends

RUN docker-php-ext-install mcrypt zip intl mbstring pdo_mysql exif \

&& docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/ \

&& docker-php-ext-install gd



ADD ./php.ini /usr/local/etc/php/

ADD ./www.conf /usr/local/etc/php/



RUN apt-get purge -y g++ \

&& apt-get autoremove -y \

&& rm -r /var/lib/apt/lists/* \

&& rm -rf /tmp/*



EXPOSE 9000

CMD ["php-fpm"]







簡単に人間の言葉で：

• ハブからphp：7-fpmイメージを取得します
• ubuntuを更新し、必要なphp拡張機能とツールを提供し、php構成をイメージにコピー（追加）し、不要なものをすべて削除し、php-fpmがリッスンするポート9000を開きます
• なじみのない詳細はADDコンストラクトだけですが、それは明らかです。最初の引数に従ってファイルを取得し、2番目の引数で指定されたパスに沿ってコンテナ内に配置します。 最初の引数は、絶対パス、相対パス、httpまたはftp urlにすることができ、このパスはフォルダーまたはアーカイブを指すこともできます。 アーカイブの場合、解凍されます。 詳細については、ADDおよびCOPYのドキュメントを参照してください。

PHPが整理されたら、nginxおよびmysqlサービスのイメージを指定し、すべてのサービスを単一のシステムに収集する必要があります。



nginxとmysqlの場合、追加の拡張機能をインストールする必要がないため、dockerfileを記述する必要さえありません。 これは、プロジェクトdocker-compose.ymlのように見えるものです



app:

build: docker/php/Dockerfile

working_dir: /app

volumes:

- ./:/app

expose:

- 9000

links:

- db

nginx:

image: nginx:latest

ports:

- "80:80"

volumes:

- ./:/app

- ./docker/nginx/vhost.conf:/etc/nginx/conf.d/vhost.conf

links:

- app

db:

image: mysql:5.7

volumes:

- /var/lib/mysql

ports:

- "3306:3306"

environment:

MYSQL_ROOT_PASSWORD: root

MYSQL_DATABASE: dbname

MYSQL_USER: dbuser

MYSQL_PASSWORD: dbpassword







ここでは、サービスはapp、nginx、dbと宣言されています。 アプリはdockerfileから組み立てられ、残りはハブからの画像を使用するだけです。



ボリュームディレクティブは、コンテナー内のホストからフォルダーをマウントするため、nginxを構成し、再起動時にデータベースデータを保存します。

linksディレクティブはサービスを相互に接続し、アプリはdbに接続されます。つまり、起動後、ホスト「db」はアプリコンテナー内で利用可能になり、対応するコンテナーを指します。



すべてがシンプル（皮肉）です。



かなりおもしろいyii2-starter-kitテンプレートがあり、そのボックスには、記述されているphp7-fpm nginx mysqlアセンブリとmailcatcherの適切な実装があります。



私のようにpythonとdjangoを好む人は、 スチームバスを浴びて、公式のDockerチュートリアル-docs.docker.com/compose/djangoに従ってすべてを行う

さらに、すべてがどのように機能するかを既に理解していれば、ニーズに合ったアセンブリを処理することは難しくありません。

落とし穴

-MacOS。 コンテナーからホスト上のサービス（mongoやmysqlなど）へのアクセス。

「Docker for Macネットワークスタック」の制限により、localhostに「取得して接続」することはできません。 ただし、次の2つの回避策があります。



a）公式かつシンプル（06/17のDockerバージョンで利用可能）-特別なDNSホスト（MacのDockerでのみ利用可能）docker.for.mac.localhostを使用して接続します。 出所



b）lo0ネットワークデバイスにIPエイリアスを追加します。

`sudo ifconfig lo0 alias 10.200.10.1 / 24`

このアドレスを使用して接続します



-MongoDB。 データ用の外部ドライブをポピーにマウントすることはできません。 理由をここで説明します。

警告（WindowsおよびOS X）：WindowsおよびOS XのデフォルトのDockerセットアップでは、VirtualBox VMを使用してDockerデーモンをホストします。 残念ながら、ホストシステムとDockerコンテナ間でフォルダーを共有するためにVirtualBoxが使用するメカニズムは、MongoDBが使用するメモリマップファイルと互換性がありません。



-Windowsでは、マウントされたボリュームのシンボリックリンクは機能しません 。 期待されていますが、他のすべてが機能した後にそれについて知ることは非常に不愉快です。



-エントリポイントとコマンドの違い - ここでは 、エントリポイントとコマンドの違いを詳細かつ明確に説明します 。



-saskasaからのUPD アドオン ：ポピーでは、コンテナからホストディスク（VOLUMEとして追加）への書き込み速度は非常に遅く、スケールを理解するには約50〜100倍です。