Dockerレシピ：モンキーパッチ、パート3

ここから、一連のメモを最初から読み始めてください： habrahabr.ru/post/267441

ローカル設定

この記事では、コマンドが実行されているのと同じマシンでdockerサービスが実行されており、プロセスが現在のフォルダーへの読み取りアクセス権を持っていると想定しています。 また、PHP-FPMとNginxの束を構成できることも意味します。



NginxとPHP 7の画像を撮ります。

~$ docker pull nginx ... ~$ docker pull php:7-fpm Status: Downloaded newer image for php:7-fpm
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、依存性注入を介してリンクする必要がある2つのエイリアンクラスができました。 誰かのコードに依存関係を追加する最も簡単な方法は、もちろん、 モンキーパッチングです！ 最初にコンテナを作成します。 プログラミングの2番目の複雑さを覚えています -コンテナーにわかりやすい名前を付けます。コンテナーが相互にやり取りできるようにするために必要です。

 ~$ docker create --name=php7 php:7-fpm 3d1b737edfcc3f1102fa54c91f9120da4b86d8cbba3092b6f80156c0e31b4d8f ~$ docker create --name=nginx nginx 80be81b27e012fd061ff4b682f0b7b8803500bc38a4b9f787f91661603b2d4b7
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Php

私はPHPから始めます-設定するのは難しいです。 PHPの設定がある場所-Dockerfileで確認できます。

  ENV PHP_INI_DIR /usr/local/etc/php --with-config-file-scan-dir="$PHP_INI_DIR/conf.d" \ WORKDIR /var/www/html COPY php-fpm.conf /usr/local/etc/
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

kontenerからphp構成ファイルを含むディレクトリの内容をコピーします

 ~$ mkdir monkeypatch ~$ cd monkeypatch/ $ docker cp php7:/usr/local/etc localetc $ ls localetc/ pear.conf php php-fpm.conf php-fpm.conf.default php-fpm.d $ ls localetc/php conf.d
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メンテナーはphp-fpm.confをイメージに入れましたが、デフォルトのphp.iniは入れませんでした。 phpソースから取得する必要があります。

 $ docker cp "$PHP7:/usr/src/php/php.ini-development" localetc/php/php.ini
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

通常どおり、構成を修正します。 PHPはどのフォルダーで拡張機能を探しますか？ たとえば、一時コンテナーでphpを実行することで確認できます。

 $ docker run --rm php:7-fpm php -i |grep extension_dir extension_dir => /usr/local/lib/php/extensions/no-debug-non-zts-20141001 => /usr/local/lib/php/extensions/no-debug-non-zts-20141001 $ docker run --rm php:7-fpm ls /usr/local/lib/php/extensions/no-debug-non-zts-20141001 opcache.a opcache.so
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

拡張機能のみのopcacheでは、接続できます。

 $ echo extension_dir = "/usr/local/lib/php/extensions/no-debug-non-zts-20141001" >> localetc/php/php.ini $ echo zend_extension = opcache.so >> localetc/php/php.ini
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

phpコンテナを再作成し、configフォルダーをマウントします。 マウントされたフォルダーへのパスはルートからのものでなければなりません-サービスは、Dockerクライアントがどのフォルダーから呼び出されたかを認識しません。

 $ docker rm php7 php7 $ docker run -v "$(pwd)/localetc:/usr/local/etc" --name=php7 php:7-fpm php -i |grep Configuration Configuration File (php.ini) Path => /usr/local/etc/php Loaded Configuration File => /usr/local/etc/php/php.ini
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、phpテストアプリケーションでphp7コンテナを再作成できます。 イメージの作成者は、php-fpmがデーモンとして機能することを確認しなかったため、標準の入出力チャネルを解放せずに、バックグラウンドで自分で実行する必要があります。

 $ docker rm php7 $ mkdir scripts $ echo " scripts/test.php $ docker run -v "$(pwd)/localetc:/usr/local/etc" \ -v "$(pwd)/scripts:/scripts" \ --name=php7 php:7-fpm & [29-Aug-2015 15:19:25] NOTICE: fpm is running, pid 1 [29-Aug-2015 15:19:25] NOTICE: ready to handle connections
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

とりあえず、デバッグの便宜上、php-fpmコンテナーからの出力をコンソールに残します。

Nginx

Nginxを使用すると、すべてがシンプルで標準になります。 configフォルダーをディスクにコピーします。

 $ docker cp nginx:/etc/nginx .
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

nginx /フォルダーで、nginx.conf、fastcgi_paramsを好みに合わせて編集し、 nginx / conf.d /にサイトの構成ファイルを作成する必要があります。 nginxがphpと通信するための主なことは、ホスト名にphpを使用してコンテナ名を指定することです。ルートおよびSCRIPT_FILENAMEディレクティブは、php7コンテナでphpが理解するパスを指す必要があります。

  location ~ \.php$ { fastcgi_pass php7:9000; fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

構成をnginxコンテナにマウントし、コンテナの80番目のポートをローカル8080にマッピングして実行します。

 $ docker rm nginx $ docker run -v "$(pwd)/nginx:/etc/nginx" -p 8080:80 --name=nginx nginx & $ curl 127.0.0.1:8080/test.php 172.17.0.65 - 29/Aug/2015:15:50:29 +0000 "GET /test.php" 200 Hello world! 7.0.0RC1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ロックンロール！



バージョン1.7では、-linkパラメーターをdocker runコマンドで指定して、他のコンテナーの名前がコンテナーで解決されるようにする必要があります。 バージョン1.8.1では、すべてがこのパラメーターなしで機能します。

ログ

PHPイメージのメンテナーは、すべてのfpmログを/ proc / self / fd / 2、別名STDERR-error_logとaccess.logの両方に書き込むことにしました。 ただし、nginxはクエリログを書き込むため、phpに関心があるのはエラーのみです。したがって、localetc / php-fpm.confを編集して、なじみのあるものを書くことをお勧めします。

 error_log = /var/log/php/php-fpm.error.log ;access.log = /proc/self/fd/2
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Nginxはイニシアチブなしでうまくいったので、nginx / conf.d / site.ru.confのサイト構成でアクセスログをオンにします

 access_log /var/log/nginx/host.access.log main;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、Dockerデーモンへの書き込み権限を持つログ用のフォルダーを作成し、コンテナーにマウントできます。 コンテナの出力は同じフォルダに書き込むこともできますが、コンテナは切り離すことができます。

 $ mkdir log $ sudo chgrp docker log/ $ sudo chmod g+rwx log/ $ docker stop nginx php7 $ docker rm nginx php7 $ docker run -d --name=php7 \ -v "$(pwd)/localetc:/usr/local/etc" \ -v "$(pwd)/scripts:/scripts" \ -v "$(pwd)/log:/var/log/php" \ php:7-fpm >>log/docker.php.log 2>&1 $ docker run -d --name=nginx \ -v "$(pwd)/nginx:/etc/nginx" \ -v "$(pwd)/log:/var/log/nginx" \ -p 8080:80 \ nginx >>log/docker.nginx.log 2>&1 $ curl 127.0.0.1:8080/test.php Hello world! 7.0.0RC1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

構成を変更する必要がある場合-再起動コマンドphpおよびnginxを指定できます。

 $ docker exec php7 pkill -o -USR2 php-fpm $ docker exec nginx service nginx reload Reloading nginx: nginx.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Debianディストリビューションにphp 7が含まれている場合、initスクリプトがphp：7イメージに表示されます。 必要に応じて、選択したディストリビューションから自分で追加できます。



継続はここにあります 。



9月23日からの補足

私のノートがトリガーしたバットサートのレベルを考えて、私は明確にします：私たちは異なる目標を持っています。 私の場合、アプリケーション、データベース、ライブラリ、およびすべての構成の完全なスタックは、数メガバイトの同じアーカイブから取り出されます。 メールで送信したり、Googleドライブにアップロードしたり、作業の結果として顧客に提供したり、チケットに添付してサーバーに展開したりできます。

管理者は、レジストリをインストールし、開発と展開の両方でそれをループし、バックアップを作成し、それを監視し、落ちたときに上げて、非常に必要です。 結構ですが、より良いです。

1つの小さなファイルにデータベースと構成を含むアプリケーションがある場合、スタック全体が1つのコマンドで解除され、同時にすべてのサービスが独立して動作します。SPOFはありません。バックアップは少なくとも直接gitで実行できます。

輸送には、レジストリ、git、rsync、ssh、およびvagrantを使用できます-制限はありません。これは別のトピックです。

すべてを1つの大きなイメージにまとめる場合、選択の余地はありません。ただ登録のために祈ってください。



PHPバージョンへのアプリケーションの依存関係は必要ありません。 スタックのいずれかの部分を変更するたびに、イメージ全体を再構築してレジストリに書き込む必要がありますか？ 私には似合わない。 PHPバージョンを更新した場合-アプリケーションを再構築していません。 MySQLを更新した場合-PHPには触れません。



はい、それはテンプレートを破ります、これは前に起こりませんでした。 この記事は、モジュール式のシステム設計が必要な人向けです。 1つの正しい方法を認識した場合、この記事はあなたに向いていません。