2022-09-05

【PlayBook概要】構築方法　２章：ホスト及びユーザ

Ansible

Playbookの各Playについて

インフラストラクチャー内のどのマシンを対象にするかどのリモートユーザがステップ(タスクと呼ばれる)を完了するか選択できます。

hosts 行は、パターン: ホストおよびグループを対象とするのドキュメントで説明されているようにコロンで区切られた１つ以上のグループまたはホストパターンのリストです。 remote_userは、ユーザーアカウントです。

Note

remote_userパラメーターは、以前はuser と呼ばれていました。 Ansible1.4で名前が変更され userモジュール(リモートシステムでユーザを作成するために使用)との区別がより明確になりました。

リモートユーザは、タスクごとに定義することも出来ます。

- hosts: webservers
  remote_user: root
  tasks:
    - name: test connection
      ping:
      remote_user: yourname

別のユーザとしての実行に関するサポートも利用可能です。権限昇格の理解：becomeを参照

- hosts: webservers
remote_user: yourname become: yes

Becomeコマンド

becomeキーワードを、play全体ではなく特定のタスクで使用することも出来ます。

- hosts: webservers
  remote_user: yourname tasks:
  service:
    name: nginx state: started
    become: yes become_method: sudo

また、自信のユーザとしてログインしてから、rootとは別のユーザになることも出来ます。

- hosts: webservers
  remote_user: yourname
  become: yes
  become_user: postgres

suなどの他の権限昇格メソッドを使用することも出来ます。

- hosts: webservers
  remote_user: yourname become: yes become_method: su

sudoのパスワードを指定する必要がある場合は ansible-playbookに--ask-become-passまたは-Kを付けて実行します。

becomeを使用してPlaybookを実行し Playbookがハングしているように見える場合はおそらく権限昇格のプロンプトでスタックしており、Control-Cを使用して停止できます。
これにより、適切なパスワードを追加してPlaybookを再実行出来ます。

important

root以外のユーザに対してbecome_userを使用すると、モジュールの引数が、/tmpのランダムな一時ファイルに簡単に記述されます。これらは、コマンドの実行直後に削除されます。

これにより、たとえば「bob」ユーザから「timmy」ユーザに特権を変更した場合に限り発生させ、「bob」から「root」に変更し場合、または「bob」または「root」として直接ログインした場合に発生させません。

このデータが、一時的に読み込み可能（書き込み不可）であることが懸念される場合、become_userを設定して暗号化されていないパスワードを転送しないでください。

その他の場合は、/tmpが使用されず、これは機能しません。Ansibleは、passwordパラメータをログに記載しないようにします。

ホストの実行順序を制御することもできます。
デフォルトは、イベントリーで指定されている順序に従います。

  - hosts: all order: sorted gather_facts:False tasks:
    debug:
      var: inventory_hostname

順序に使用できる値は以下のとおりです。

項目	説明
inventory	デフォルトです。インベントリーで「提供されたとおり」の順序になります。
reverse_inventory	名前が示すように、インベントリーで「提供されたとおり」のものと逆の順序になります
sorted	ホストの名前をアルファベット順で並べます
reverse_sorted	ホストの名前を逆アルファベット順で並べます
shuffle	ホストは実行ごとにランダムに並べられます

2022-09-04

【PlayBook概要】構築方法　１章： Playbookについて

Ansible

Playbookについて

Playbookとは、アドホックタスク実行モードとは完全に異なる方法でAnsibleを使用する。
Playbookはは、既存のものとは異なり、非常にシンプルな構成管理とマルチマシンデプロイメントシステムの基礎となりますが、複雑なアプリケーションのデプロイメントに非常に適しています。
Playbookは構成を宣言できますが特定の順序でマシンセット間でのさまざまなステップを往復する必要がある場合でも 手動で指定したプロセスのステップを調整することも出来ます。同期または非同期で、タスクを起動可能
アドホックタスク用にメインの/usr.bin/ansibleプログラムを実行する場合がありますが Playbookはソース管理に保持され、構成をプッシュしたり、リモートシステムの構成が仕様どおりであることを確認したりするためのに使用される可能性が高くなります。

ansible-examples repositoryで、これらの手法を多数説明している
Playbookの全セットもあります。

単語帳

アドホックタスク

プロセス作成時に定義しきれなかった隠れたタスクを、プロセスの実行中に追加することのできるタスクです。

デプロイメント

コンピューターネットワークを通じて提供されるアプリケーションやウェブ上のサービスを、利用可能な状態にすること

Playbook言語の例

各Playbookは、リストにある１つ以上のPlaysから構成
Playの目的は、ホストのグループを、Ansibleではタスクと呼ばれるもに代表される明確に定義されたロールにマッピングすることです。基本的なレベルでは、タスクはAnsibleモジュールを呼び出します。
複数のPlayのPlaybookを作成することにより、マルチマシンデプロイメントを調整して webserversグループのすべてのマシンで特定のすステップを実行し次にdatabaseサーバグループで特定のステップを実行しさらにwebserversグループでさらに多くのコマンドを実行できる。
Playは多かれ少なかれスポーツに似ています。さまざまな事を行うために、システムに影響を与える多くのplayを持つことが出来ます。特定の状態またはモデル定義するだけではなく、様々なplayを同時に実行することが可能。

単語帳

ロールマッピング

実行時にユーザまたはグループをセキュリティロールに動的に割り当てるプロセス。

Playbookには複数のプレイを含めることが出来ます。
最初にWebサーバを対象として、
次にデータベースサーバを対象とするPlaybookがある場合

例：

- hosts: webservers
  remote_user: root

  tasks:
  - name: ensure apache is at the latest version
    yum:
      name: httpd
      state: latest
  - name: write the apache config file
    template:
      src: /srv/httpd.j2
      dest: /etc/httpd.conf

- hosts: databases
  remote_user: root

  tasks:
  - name: ensure postgresql is at the latest version
    yum:
      name: postgresql
      state: latest
  - name: ensure that postgresql is started
    service:
      name: postgresql
      state: started

この方法を使用して

対象とするホストグループ、リモートサーバにログインすユーザ名 sudoを使用するかどうかなどを切り替える事ができます。 playはタスクと同様に、Playbookで指定された順序で上から下に実行されます。

2020-05-17

Dockerセットアップ第７弾

Dcoker

CPU,メモリーの利用制限の設定

1.GoogleCloudのIaas環境の確認

現在、稼働中のIaas環境のスペックは以下の通り

MachineType:g1-small
Cpu:1core
Memory:1.7GB

2.現在のdockerのリソース状況を確認

以下のコマンドにて確認する。
実行後のキャンセルはCtrl + shift ＋ cを押下し停止する。

$ sudo docker stats

#実行結果は以下の通り
CONTAINER ID        NAME                    CPU %               MEM USAGE / LIMIT     MEM %               NET I/O  
           BLOCK I/O           PIDS
d25975f7bb09        growi_app_1             0.24%               75.91MiB / 1.654GiB   4.48%               215kB / 1
64kB       0B / 0B             39
bf48e2e6e690        growi_mongo_1           0.54%               48.38MiB / 1.654GiB   2.86%               160kB / 2
10kB       0B / 0B             31
80dd8db700d6        growi_elasticsearch_1   0.47%               487.9MiB / 1.654GiB   28.80%              698B / 42
B          0B / 0B             39
cab35b40eda7        yml_node_1              0.00%               6.27MiB / 1.654GiB    0.37%               1.13kB / 
0B         0B / 0B             7
2d99643f9b9f        docker-knowledge        0.15%               247MiB / 1.654GiB     14.58%              179kB / 1
87kB       0B / 0B             46
86e5b162d74f        postgres                0.00%               6.906MiB / 1.654GiB   0.41%               129kB / 1
59kB       0B / 0B             9
c28a409a997e        reverse-proxy           0.00%               1.48MiB / 1.654GiB    0.09%               75.7kB / 
77.3kB     0B / 0B             2

実行停止は以下もコマンドで

Ctrl + shift ＋ c

３.各コンテナへの割り振りの設定

各ミドルウェアのコンテナに対して、CpuとMemoryの割り振りを行う

MiddleWareName	Cpu	Memory
docker-knowlege	1	500MB
postgres	0.50	100MB
reverse-proxy	1	500MB

3-1.docker-compose.ymlファイルの設定を変更する。

以下のdocker-compose.ymlを元に準備する。

version: '3'
#swarm-mode対応http://docs.docker.jp/engine/swarm/index.html
services:
   app:
      image: koda/docker-knowledge:latest
      #コンテナ名を明示的に指定する
      container_name: docker-knowledge
      volumes:
         - /usr/local/etc/knowledge/webapps:/usr/local/tomcat/webapps
      ports:
         - 8080:8080
      restart: always
      tty: true
      #dbが起動してからappが起動する．
      deploy:
       replicas: 1 # 起動するプロセスの数
       resources:
        limits:
          cpus: '1'
          memory: 500M
      depends_on:
         - db

   proxy:
      image: nginx:latest
      #コンテナ名を明示的に指定する
      container_name: reverse-proxy
      volumes:
         - /usr/local/etc/knowledge/html:/usr/share/nginx/html
         - /usr/local/etc/knowledge/nginx/conf.d/:/etc/nginx/conf.d    
      ports:
         - 80:80
      restart: always
      tty: true
      deploy:
       replicas: 1 # 起動するプロセスの数
       resources:
        limits:
          cpus: '0.50'
          memory: 100M

   db:
      image: postgres:latest
      #コンテナ名を明示的に指定する
      container_name: postgres
      
      #コンテナの環境変数を追加する。
      #build オプションと合わせて指定すると、build中は enviroment で指定した
      #環境変数は見えないことに注意。
      #build に変数を渡す場合は args オプションで指定する。
      environment:
         - POSTGRES_USER=postgres
         - POSTGRES_PASSWORD=admin123
         - POSTGRES_DB=docker_knowledge
      volumes:
         - /usr/local/etc/knowledge/postgres/data:/var/lib/postgresql/data
      restart: always
      tty: true
      deploy:
       replicas: 1 # 起動するプロセスの
       resources:
        limits:
          cpus: '1'
          memory: 500M

3-2.deployについて

以下の指定はサービスの定義を示します。
サービスの定義とは、そのサービスを起動する各コンテナーに適用される設定を行うことです

deploy:
 replicas: 1 # 起動するプロセスの数
 resources:
  limits:
   cpus: '1'
   memory: 500M

3-2.replicasについて

サービスを replicated（デフォルト）に設定しているときに、起動させるコンテナー数を指定します。

replicas: 1

3-3.resourcesについて

リソースの制約を設定します。

resources:

3-4.CpuとMemory制限の設定

以下の記載で利用可能なプロセス時間を設定可能
設定内容は以下の通り

項目	ハードウェア名	設定値	備考
利用可能なプロセス時間	Cpu	1	シングルコアの100%
メモリ利用	Memory	500M

resources:
 limits:
   cpus: '1'
   memory: 500M

利用する領域の予約もできる。

以下のように設定を追記すると可能
ホストのメモリに余裕がある時はは制限はかからず、他に使用している時に制限が掛かる。
利用予約の設定は以下の通り

項目	ハードウェア名	設定値	備考
最低利用可能なプロセス時間	Cpu	0.25	常時利用可能な領域
最低メモリ	Memory	20M	常時利用可能な領域

resources:
 limits:
   cpus: '1'
   memory: 500M
#以下の設定が該当の箇所になります。
reservations:
   cpus: '0.25'
   memory: 20M

４．Swarm(スウォーム)モード利用でコンテを起動させる。

予めにSwarm クラスタを初期化させる

docker swarm init

4-1.Swarmモードにてコンテナを起動させる

deployを設定した場合は以下のコマンドにてSwarm(スウォーム)モードを利用する必要がある

sudo docker stack deploy -c <ymlファイル名>　<アプリケーション名(任意の名前 なんでも可）>

#下記、起動例になります。
sudo docker stack deploy -c docker-compose-proxy-posgre.yml proxy-posgre

4-2.Swarmモードにてコンテナを更新し起動させる

docker-compose.ymlファイルを更新した際は、起動時と同じく以下のコマンドを実行すれば、更新され起動される。

sudo docker stack deploy -c <ymlファイル名>　<起動時に設定したアプリケーション名>

#下記、更新後の起動例になります。
sudo docker stack deploy -c docker-compose-proxy-posgre.yml proxy-posgre

4-5.アプリケーションとSwarmの解体（停止）

アプリケーションを削除（remove）しますが、１つの swarm ノードは起動および実行したままになりますので、注意してください。

sudo docker stack rm <起動時に設定したアプリケーション名>

#下記、停止例になります。
sudo docker stack rm proxy-posgre

4-6.Swarmのクラスタ停止

Swarm （クラスタ）を停止するには以下のコマンドを実行

docker swarm leave --force

4-6.アプリケーション名の調べ方

アプリケーション名の一覧を確認する場合は以下のコマンドを実行

sudo docker stack ls

#実行結果は下記の通り

NAME                SERVICES            ORCHESTRATOR
proxy-posgre        4                   Swarm

swarm起動ではない場合は

docker-composeのversionを下げて2を指定し以下のコマンドを利用すると行えます。

詳細はこちら

一例になります。

cpu_count: 2
cpu_percent: 50
cpus: 0.5
cpu_shares: 73
cpu_quota: 50000
cpu_period: 20ms
cpuset: 0,1

user: postgresql
working_dir: /code

domainname: foo.com
hostname: foo
ipc: host
mac_address: 02:42:ac:11:65:43

mem_limit: 1000000000
memswap_limit: 2000000000
mem_reservation: 512m
\

５．起動後の確認

5-1.起動中のコンテナの確認

以下のコマンドにて起動しているコンテナを一覧表示

docker service ls

#実行結果は下記の通り

ID                  NAME                  MODE                REPLICAS            IMAGE                          PORTS
uw79m4zr9pgw        proxy-posgre_app      replicated          1/1                 koda/docker-knowledge:latest   *:8080->8080/tcp
332hcv6qzxvc        proxy-posgre_backup   replicated          0/1                 backup-service:latest          
odhal10l3xpe        proxy-posgre_db       replicated          1/1                 postgres:latest                
tidwvuer0wu1        proxy-posgre_proxy    replicated          1/1                 nginx:latest                   *:80->80/tcp

5-2.起動中のコンテナ数の確認

以下のコマンドにて起動しているコンテナを一覧表示

sudo docker stack ps <起動時に設定したアプリケーション名>

#実行結果は下記の通り

   PORTS
w5crmrcb0bs0        proxy-posgre_backup.1       backup-service:latest          project             Ready               Rejected less than a second ago   "No such image: backup-service…"   
rge95ljgfnxn         \_ proxy-posgre_backup.1   backup-service:latest          project             Shutdown            Rejected 5 seconds ago            "No such image: backup-service…"   
pv3g850wzznh         \_ proxy-posgre_backup.1   backup-service:latest          project             Shutdown            Rejected 10 seconds ago           "No such image: backup-service…"   
lw0e4uieya7i         \_ proxy-posgre_backup.1   backup-service:latest          project             Shutdown            Rejected 15 seconds ago           "No such image: backup-service…"   
bw1xxjw8iosd         \_ proxy-posgre_backup.1   backup-service:latest          project             Shutdown            Rejected 20 seconds ago           "No such image: backup-service…"   
u1cgs6dn9voc        proxy-posgre_db.1           postgres:latest                project             Running             Running 31 hours ago                                                 
pvf4wg7nyxzb         \_ proxy-posgre_db.1       postgres:latest                project             Shutdown            Failed 31 hours ago               "starting container failed: fa…"   
70b2olguiis3        proxy-posgre_app.1          koda/docker-knowledge:latest   project             Running             Running 31 hours ago                                                 
lw1wmcjoiwc9        proxy-posgre_proxy.1        nginx:latest                   project             Running             Running 31 hours ago                                                 
w51pp66yorc7        proxy-posgre_db.1           postgres:latest                project             Shutdown            Shutdown 31 hours ago                                                
i5zkppmksh7n        proxy-posgre_proxy.1        nginx:latest                   project             Shutdown            Failed 31 hours ago               "error while removing network:…"   
qw469yr4xp8o        proxy-posgre_app.1          koda/docker-knowledge:latest   project             Shutdown            Failed 31 hours ago               "error while removing network:…"

参考サイト

【公式】Docker-Compose_ver.3 リファレンス

【公式】docker stack deployについて

【公式】swarm initについて

【公式】docker stack deployについて

【公式】kubeadmのインストール

Docker (ファイル/CPU/メモリ/プロセス) のリソースを制限する方法まとめ

Docker Compose/Swarm 入門

Docker_ver.1.12.1のメモリ制限に関するメモ

Docker-composeとDocker stack について

Dockerコンテナで利用できるリソースや権限を制限する

2020-05-11

Dockerセットアップ第６弾

Dcoker

docker-knowledgeの書き込み先をPostgresに変更

１.完成形のdocker-compose.ymlファイルの内容を確認

以下のdocker-compose.ymlを元に準備する。

version: '3'
#swarm-mode対応http://docs.docker.jp/engine/swarm/index.html
services:
   app:
      image: koda/docker-knowledge:latest
      #コンテナ名を明示的に指定する
      container_name: docker-knowledge
      volumes:
         - /usr/local/etc/knowledge/webapps:/usr/local/tomcat/webapps
      ports:
         - 8080:8080
      restart: always
      tty: true     
      #dbが起動してからappが起動する．
      depends_on:
         - db

   proxy:
      image: nginx:latest
      #コンテナ名を明示的に指定する
      container_name: reverse-proxy
      volumes:
         - /usr/local/etc/knowledge/html:/usr/share/nginx/html
         - /usr/local/etc/knowledge/nginx/conf.d/:/etc/nginx/conf.d    
      ports:
         - 80:80
      restart: always
      tty: true

   db:
      image: postgres:latest
      #コンテナ名を明示的に指定する
      container_name: postgres
      
      #コンテナの環境変数を追加する。
      #build オプションと合わせて指定すると、build中は enviroment で指定した
      #環境変数は見えないことに注意。
      #build に変数を渡す場合は args オプションで指定する。
      environment:
         - POSTGRES_USER=postgres
         - POSTGRES_PASSWORD=admin123
         - POSTGRES_DB=docker_knowledge
      volumes:
         - /usr/local/etc/knowledge/postgres/data:/var/lib/postgresql/data
      restart: always
      tty: true

２.postgresの環境設定

environmentを用いて環境変数を設定する。

下記のdocker-hubのEnvironment Variablesを参照 docker-hub postgres

environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=admin123
      - POSTGRES_DB=docker_knowledge

３.postgresのデータ保存先をマウント設定

environmentを用いて環境変数を設定する。
１.ホストにpostgresのフォルダを作成

#nginxフォルダを作成
mkdir /usr/local/etc/knowledge/postgres

+　２.docker-composeのdocker-compose.ymlのdbのvolumesを以下のように設定しマウントさせる。

volumes:
    - /usr/local/etc/knowledge/postgres/data:/var/lib/postgresql/data

３.上記１から２を行い、コンテナ再起動を行うと設定が反映される

docker-compose -f  [ymlファイル名] up -d

Dockerの起動後のログ確認について

以下のような時にログが見たい場合のコマンドです。

docker起動後にエラーで起動できない時
起動しても画面が表示出来ない。
起動後の動作確認を行いたい。

sudo docker logs -t <dockerID or dockerName>

#ログ確認コマンド：例
sudo docker logs -t postgres

参考サイト

PostgreSQL 9.3 の JSON サポートについて（長いよッ） - Qiita

Dockert調査　~ログ編~ - Qiita

2020-05-11

Dockerセットアップ第５弾

Dcoker

docker-knowledgeをNginx経由に変更

１.完成形のdocker-compose.ymlファイルの内容を確認

以下のdocker-compose.ymlを元に準備する。

version: '3'
#swarm-mode対応http://docs.docker.jp/engine/swarm/index.html
services:
   app:
      image: koda/docker-knowledge:latest
      #コンテナ名を明示的に指定する
      container_name: docker-knowledge
      volumes:
         - /usr/local/etc/knowledge/webapps:/usr/local/tomcat/webapps
      ports:
         - 8080:8080
      restart: always
      tty: true     
      #dbが起動してからappが起動する．
      depends_on:
         - db

   proxy:
      image: nginx:latest
      #コンテナ名を明示的に指定する
      container_name: reverse-proxy
      volumes:
         - /usr/local/etc/knowledge/html:/usr/share/nginx/html
         - /usr/local/etc/knowledge/nginx/conf.d/:/etc/nginx/conf.d    
      ports:
         - 80:80
      restart: always
      tty: true

   db:
      image: postgres:latest
      #コンテナ名を明示的に指定する
      container_name: postgres
      
      #コンテナの環境変数を追加する。
      #build オプションと合わせて指定すると、build中は enviroment で指定した
      #環境変数は見えないことに注意。
      #build に変数を渡す場合は args オプションで指定する。
      environment:
         - POSTGRES_USER=postgres
         - POSTGRES_PASSWORD=admin123
         - POSTGRES_DB=docker_knowledge
      volumes:
         - /usr/local/etc/knowledge/postgres/data:/var/lib/postgresql/data
      restart: always
      tty: true

２.docker-knowledgeのパスを「/knowledge」に変更

docker-knowledgeをそのままインストールすると以下のURLになる。

http://<グローバルIP>/open.knowledge/list

上記のURLを以下のように変更させる

http://<グローバルIP>/knowledge/open.knowledge/list

３.docker-knowledgeの「warファイル」を「knowledge.war」も増やす

docker-knowledgeの以下のパスにROOT.warがある。

/usr/local/tomcat/webapps/ROOT.war

上記のROOT.warファイルをコピーしknowledge.warリネームする

cp /usr/local/tomcat/webapps/ROOT.war /usr/local/tomcat/webapps/knowledge.war

やり方

１.下記のコマンドでdocker-knowledgeのコンテナに入る。

docker-compose exec app bash

２.下記のコマンドを実行しknowledge.warを作成する。

cp /usr/local/tomcat/webapps/ROOT.war /usr/local/tomcat/webapps/knowledge.war

３.tomcatを停止して、起動させ反映させる。

/tomcat/bin/catalina.sh stop
/tomcat/bin/catalina.sh run

但し、このやり方だとコンテナを再構築した際に再設定が必要

以下の方法がオススメ

１.ホストにknowledgeのフォルダを作成

#knowledgeフォルダを作成
mkdir /usr/local/etc/knowledge

２.コンテナからにwebappsのフォルダごとホスト側へ転送 Dockerのファイル転送について

docker cp docker-knowledge:/usr/local/tomcat/webapps ./

３.転送したwebappsフォルダをホストのknowwledgeフォルダへ移動

mv ./webapps /usr/local/etc/knowledge

４.docker-composeのdocker-compose.ymlのappのvolumesを以下のように設定しマウントさせる。

#サービス名「app」のvolumes
volumes:
    - /usr/local/etc/knowledge/webapps:/usr/local/tomcat/webapps

５.上記１から４を設定すると以下のコマンドでコンテナ再起動しても設定は消えない

docker-compose -f  [ymlファイル名] up -d

４.Nginxコンテナにリバースプロキシの設定を行う

1.ホストにnginx/conf.dのフォルダを作成

#nginxフォルダを作成
mkdir /usr/local/etc/knowledge/nginx
#次にconf.dフォルダを作成
mkdir /usr/local/etc/knowledge/conf.d

ホストのconf.dフォルダに移動しdefault.conf(nginx.conf)を作成しconfの中身を以下のように記述し設定する。

server {
    listen       80;
    server_name  localhost;

    map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
    }

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }

    location /knowledge {
        proxy_pass http://xx.xx.xx.xx:8080/knowledge;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_redirect http:// https://;
    }

    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }

    location ~ /\.ht {
        deny  all;
    }
}

default.conf(nginx.conf)の以下の部分がdocker-knowledgeとリバースプロキシ設定部分

location /knowledge {
    proxy_pass http://xx.xx.xx.xx:8080/knowledge;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_set_header Host $host;
    proxy_cache_bypass $http_upgrade;
    proxy_redirect http:// https://;
}

default.conf(nginx.conf)作成後、docker-composeのdocker-compose.ymlのproxyのconf.dフォルダをホストのconf.dフォルダとマウントさせる。

#サービス名「proxy」のvolumes
volumes:
    - /usr/local/etc/knowledge/nginx/conf.d/:/etc/nginx/conf.d

変更後、以下のコマンドでdocker-composeを起動させコンテナを再起動し反映させる。

docker-compose -f  docker-compose.yml up -d

Dockerのファイル転送について

dockerのファイル転送マニュアル

ホスト(ローカル)からコンテナへ転送方法

docker cp [オプション] ローカル・パス|- コンテナ名:パス
docker cp /tmp/local_file.php container_test1:/tmp/local_copy_file.php

※コピー先にファイルを指定しない場合には新しく作成されます。

コンテナからホスト(ローカル)へ転送方法

docker cp [オプション] コンテナ名:パス ローカル・パス|-
docker cp container_test1:/tmp/container_file.php /tmp/container_copy_file.php

Nginxのproxy設定について

proxy_http_versionについて

HTTPプロトコルバージョンを指定します。
webソケットに必要なkeep-aliveはバージョン1.1以降で利用可能ですが デフォルトでは1.0なので明示的に指定する必要があります。

※下記の「proxy_set_header Upgrade」や「proxy_set_header Connection」も1.1以降でのみ利用可能なヘッダ設定です。

proxy_http_version 1.1;

proxy_set_header Upgrade $http_upgradeについて

プロトコルスイッチという仕組みで通信プロトコルをHTTP/1.1からwebsocketに変更します。
プロコルスイッチはHTTP/1.1から利用可能になった仕組みです。先ほどの公式の記事に記載があります。

proxy_set_header Upgrade $http_upgrade;

詳細: ここで紹介しているUpgradeと次のConnectionは、Hop-by-hopヘッダと呼ばれる特殊なヘッダ情報です。通常のEnd-to-endヘッダは情報を最終的な宛先に届けるために使用するのに対し、Hop-by-hopヘッダは（存在する場合は）プロキシに対して値を渡すために使用されます。

参照：HTTPプロキシでのヘッダ制御

proxy_set_header Connection upgrade|closeについて

送信先にコネクションを維持するか否かを伝えるためのヘッダーです。
$http_upgradeの値に応じて設定済みの、「upgrade」あるいは「close」を設定

proxy_set_header Connection $connection_upgrade;

proxy_set_header Host $hostについて

設定を入れないとnginxによるリバースプロキシでは、HTTPのHostヘッダがnginxにより書き換えられてバックエンドのサーバに伝わる。
これを防ぐため、以下の設定を行い、バックエンドのサーバにも、nginxにアクセスされた時と同様のHostヘッダを付与させるように出来る。

proxy_set_header Host $host;

proxy_cache_bypassについて

キャッシュ（した値）を使わないレスポンスを定義。
`stringに指定した値($http_upgradeなどの値)'すべてが空、あるいは０の時はレスポンスに対してキャッシュを使わない

proxy_cache_bypassについて

proxy_cache_bypass <string> 

#記載例：
proxy_cache_bypass $http_upgrade;

おまけ1　proxy_no_cacheについて

キャッシュに取らないレスポンスを定義。
proxy_cache_bypassと同様に`stringに指定した値($http_upgradeなどの値)'すべてが空、あるいは０の時はレスポンスに対してキャッシュを使わない

proxy_no_cache <string> 

#記載例：
proxy_no_cache $http_upgrade;

おまけ2　proxy_cache_keyについて

キャッシュするキーを指定。

proxy_cache_key <string> 

#記載例：
proxy_cache_key $scheme$proxy_host$request_uri;

おまけ3　proxy_cache_validにつて

キャッシュされたレスポンスのうち、ステータスコードを指定してその対象の有効時間を制限する。
デフォルトだとレスポンスがキャッシュされる時間は無制限。キャッシュのファイルストレージ超過時に使用されていないものから削除される。
すべてのステータスコードを指定する場合はコードの代わりに anyを指定する。

proxy_cache_valid [code ...] time

#記載例：
#以下の記述例だと、200と302コードのレスポンスはキャッシュの中では10分間有効になる。
proxy_cache_valid 200 302 10m;

proxy_redirectについて

以下の設定を行うとリダイレクトの際、httpをhttpsへ変換して行うことが出来る。

proxy_redirect http:// https://;

参考サイト

Qiitaライクのknowledgeをdocker-composeで楽々導入って記事をQiitaであげる暴挙 - Qiita

Docker を使ってデータの永続化をせずにマストドンをデプロイしてしまったときの対処法 - Qiita

dockerコンテナにファイルを転送する - Qiita

DockerでNginxイメージを利用し、リバースプロキシを構築してみる - Qiita

実践編ーDockerを使ってnginxでリバースプロキシを立ててみる - Qiita

NginxのリバースプロキシでWebソケットを通す際の設定 - Qiita

NginxのWebSocket利用時の設定

proxy_cache_bypassの説明など - Qiita

NGINX コンテントのキャッシング | NGINX 日本語訳

ngx_http_proxy_module モジュール日本語訳

Playbookの各Playについて

Note

Becomeコマンド

important

Playbookについて

単語帳

Playbook言語の例

単語帳

この方法を使用して

1.GoogleCloudのIaas環境の確認

2.現在のdockerのリソース状況を確認

実行停止は以下もコマンドで

３.各コンテナへの割り振りの設定

3-1.docker-compose.ymlファイルの設定を変更する。

3-2.deployについて

3-2.replicasについて

3-3.resourcesについて

3-4.CpuとMemory制限の設定

利用する領域の予約もできる。

４．Swarm(スウォーム)モード利用でコンテを起動させる。

4-1.Swarmモードにてコンテナを起動させる

4-2.Swarmモードにてコンテナを更新し起動させる

4-5.アプリケーションとSwarmの解体（停止）

4-6.Swarmのクラスタ停止

4-6.アプリケーション名の調べ方

swarm起動ではない場合は

５．起動後の確認

5-1.起動中のコンテナの確認

5-2.起動中のコンテナ数の確認

参考サイト

１.完成形のdocker-compose.ymlファイルの内容を確認

２.postgresの環境設定

３.postgresのデータ保存先をマウント設定

Dockerの起動後のログ確認について

参考サイト

１.完成形のdocker-compose.ymlファイルの内容を確認

２.docker-knowledgeのパスを「/knowledge」に変更

３.docker-knowledgeの「warファイル」を「knowledge.war」も増やす

やり方

但し、このやり方だとコンテナを再構築した際に再設定が必要

４.Nginxコンテナにリバースプロキシの設定を行う

Dockerのファイル転送について

ホスト(ローカル)からコンテナへ転送方法

コンテナからホスト(ローカル)へ転送方法

Nginxのproxy設定について

proxy_http_versionについて

proxy_set_header Upgrade $http_upgradeについて

proxy_set_header Connection upgrade|closeについて

proxy_set_header Host $hostについて

proxy_cache_bypassについて

おまけ1 proxy_no_cacheについて

おまけ2 proxy_cache_keyについて

おまけ3 proxy_cache_validにつて

proxy_redirectについて

参考サイト

おまけ1　proxy_no_cacheについて

おまけ2　proxy_cache_keyについて

おまけ3　proxy_cache_validにつて