Dockerセットアップ 第4弾
DockerComposeのymlファイル作成と起動
1.docker-knowledgeのymlファイルを作成
- 以下のShellファイルを作成
version: '3' #swarm-mode対応http://docs.docker.jp/engine/swarm/index.html services: app: image: koda/docker-knowledge:latest #コンテナ名を明示的に指定する container_name: docker-knowledge volumes: - /home/nomura_r_104/knowledge:/root/.knowledge - /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
1-1.versionについて
- 以下の指定は
docker-compose
のファイルバージョンを指定している docker-composeファイルバージョン3-リファレンスはこちら
version: '3'
1-2.serviceについて
- 以下の指定は
サービスの定義
を示します。 - サービスの定義とは、そのサービスを起動する各コンテナーに適用される設定を行うことです
service:
1-3.service名について
- 起動するコンテナのサービス名の定義を示します。
- サービス名はコンテナにあった自由なサービス名を定義することが可能
app:
1-4.imageについて
- dockerのイメージファイルの定義を示します。
- [イメージ名]:[バージョン]を記載します。
- Dockerのイメージ一覧はこちら
image: koda/docker-knowledge:latest
1-5.container_nameについて
- コンテナの名前の定義を示します。
container_name: docker-knowledge
1-6.container_nameについて
- コンテナの名前の定義を示します。
container_name: docker-knowledge
1-7.volumesについて
データを永続化できる場所の定義を示します。
コンテナ内部にデータ(ファイル)を保存しても、コンテナ破棄すると消えてしまう。
- データを永続化したいときは、コンテナの外にデータを置く必要がある。
- その場所のことを、ボリュームと呼ぶ。
記述方法1
[マウントするホストサーバ側のフォルダを指定]:[コンテナのマウントするフォルダを指定]
volumes: - /home/nomura_r_104/knowledge:/root/.knowledge - /usr/local/etc/knowledge/webapps:/usr/local/tomcat/webapps
記述方法2(コンテナ名指定も可能)
- 指定したコンテナ名がマウントしているボリュームを同じマウントポイントで共有できる。
volumes-from: <Container Name> #例:上記の「volumes」のマウントポイントを共有 #volumes: # - /home/nomura_r_104/knowledge:/root/.knowledge # - /usr/local/etc/knowledge/webapps:/usr/local/tomcat/webapps
1-8.portsについて
- ホストのポートとコンテナのポートをマッピングしてforwardingを行います。
記述方法
[ホストのポート番号を指定]:[コンテナのポート番号を指定]
- 以下の記載も可能 [ホストのIPを指定]:[ホストのポート番号を指定]:[コンテナのポート番号を指定]
ports: - 8080:8080
- 注意事項
- HOST:CONTAINER形式でポートをマッピングする場合、60未満のコンテナポートを使用すると、YAMLがxx:yyの形式の数値を60進数の値として解析するため、誤った結果が生じる可能性があります。このため、ポートマッピングを常に文字列として明示的に指定することをお勧めします。
1-9.restartについて
- 再起動ポリシーの定義を示します。
- 再起動ポリシーとは、コンテナが終了時に再起動すべきかどうかを定義します。
restart: always
ポリシー | 結果 |
---|---|
no (なし) | コンテナが終了しても、自動的には再起動しません。これがデフォルトです。 |
on-failure [:最大リトライ数] | コンテナが 0 以外の終了コードで停止したら再起動します。オプションで Docker デーモンが何度再起動を試みるかを指定できます。 |
always (常に) | コンテナの終了コードに拘わらず、常にコンテナの再起動を試みます。Docker デーモンは無制限に再起動を試みます。また、デーモンの起動時にも、コンテナの状況に拘わらず常に起動を試みます。 |
unless-stopped (停止していない場合) | コンテナの終了コードに拘わらず、常にコンテナの再起動を試みます。しかし、直近のコンテナが停止状態であったのであれば、デーモンの起動時にコンテナを開始しません。 |
1-10.ttyについて
- コンテナの起動維持の設定を示します。
- コンテナに疑似TTY(標準出力の接続先デバイス)を割り当てる
- tty:trueと書くと常時起動が可能となる。
tty: true
- tty
- 標準出力の接続先デバイス
1-11.depends_onについて
- サービスの起動順番を示します。
- サービスの起動順番を制御
- Compose は常に依存関係に従ってコンテナを起動しようとします。
- 依存関係とは、
depends_on
,links
,volumes_form
,network_mode:
,サービス:...
を指定している場合です。
depends_on: - db
1-12.environmentについて
- コンテナの環境変数を追加する。
- build オプションと合わせて指定すると、build中は enviroment で指定した環境変数は見えないことに注意。
- buildに変数を渡す場合は args オプションで指定する。
environment: - POSTGRES_USER=postgres - POSTGRES_PASSWORD=admin123 - POSTGRES_DB=docker_knowledge
/usr/local/tomcat/webapps/ROOT.war -> knowledge.war
2.docker-composeの起動
- 以下のコマンドでdocker-composeを起動させる。
docker-compose -f [ymlファイル名] up -d
2-1.-f
について
-f
を利用してyml指定してコンテナ起動を行うことが出来る。
docker-compose -f [ymlファイル名]
2-2.up
について
up
を指定するとコンテナの構築・起動まで行います。- キャッシュがある場合はそれを使って一発でイメージの構築から、コンテナの構築・起動までします。
- imageがなくてもbuildから実行してくれます。
docker-compose -f [ymlファイル名] up
- 注意
- 新しいサービスを初めて立ち上げる場合はもちろんキャッシュはないので docker-compose up --build コマンドを利用する
2-3.-d
について
- デタッチモード(分離するという意味)
- -dをつけることでバックグラウンドで実行することができます。
- コンテナ内に入らず、バックグラウンドでコンテナを動作させる。
docker-compose -f [ymlファイル名] up -d
- 補足説明
- 一般的には docker-compose up が使われるでしょう。 up を使うと docker-compose.yml ファイル中で定義したサービスの開始または再起動を行います。デフォルトは「アタッチド」モードであり、全てのコンテナのログが画面上に表示されます。「デタッチド」モード( -d )では、Compose はコンテナを実行すると終了しますが、コンテナは後ろで動き続けます。
3.docker-composeの停止
- 以下のコマンドでdocker-composeを停止させる。
docker-compose -f [ymlファイル名] stop
3-1.stop
について
stop
を指定するとコンテナの起動停止を行います。
docker-compose -f [ymlファイル名] stop
4.docker-composeのその他コマンドについて
- docker-composeのコマンドは多く代表的なものを記載
4-1.start
について
start
を指定するとコンテナの起動を行います。- サービスを開始します。これは既にコンテナがある状態でなければなりません。
docker-compose -f [ymlファイル名] start
4-2.ps
について
ps
を指定するとdokcer-composeのサービス名の一覧を表示します。起動を行います。
docker-compose ps
4-3.exec
について
- サービスに対する任意のコマンドを実行することができます。
- 以下の様に「bash」起動してコンテナに入ることも可能です。
#サービス名「db」を指定しpostgresのコンテナに入ります。 docker-compose -f [ymlファイル名] exec db bash
- docker -compose exec
- コマンドはデフォルトでは TTY が割り当てられます。なので、「docker exec -it [docker name] bash)」みたに「-it」を指定する必要がない
- bash起動
- 「bash」起動させることで、通常のOSと同じ様にシェルコマンド(ls,cd,mv,cpなど)でコンテナ内を操作できる。
- dockerの場合
- 「docker exec -it [docker name] bash」を指定します。
フォアグラウンドとデタッチの違いについて
- 図1:以下の様に双方利用用途が異なります。
- 図2:フォアグラウンドのメリットとデメリットは以下の通り。
- 図3:デタッチ(バックグラウンド起動)のメリットとデメリットは以下の通り。
- 図4:デタッチ(バックグラウンド起動)時のアプリケーション常時起動の解決方法その1
- 図5:デタッチ(バックグラウンド起動)時のアプリケーション常時起動の解決方法その2
DockerComposeの起動時にエラーが発生した場合の対処方法
DockerComposeの起動時エラー
- DockerComposeの起動コマンドを実行した際に
下記のエラーが発生
した際の対処方法
ERROR: Couldn't connect to Docker daemon at http+docker://localhost - is it running? If it's at a non-standard location, specify the URL with the DOCKER_HOST environment variable.
エラーの対処方法
- 原因としてアカウント権限の
dockerグループが存在しない
と発生する。 - 対象方法として、以下のように
新規でdockerグループを作成
し、それに対して実行するアカウント
をグループに所属
させると解消する。
# dockerグループがなければ作る sudo groupadd docker # 現行ユーザをdockerグループに所属させる sudo gpasswd -a $USER docker # dockerデーモンを再起動する (CentOS7の場合) sudo systemctl restart docker # exitして再ログインすると反映される。 exit
参考サイト
Docker、ボリューム(Volume)について真面目に調べた - Qiita
Docker の Data Volume まわりを整理する - Qiita
よくある質問と回答 — Docker-docs-ja 17.06.Beta ドキュメント
Compose file version3のリファレンス - Qiita
docker-compose の ports 指定まとめ - Qiita
Docker 上の nginx で Mattermost と Knowledge と Joomla をリバースプロキシさせてみた Ver.1 - Qiita
docker-compose コマンドまとめ - Qiita
docker-compose up
とか build
とか start
とかの違いを理解できていなかったのでまとめてみた。 - Qiita
Dockerセットアップ 第3弾
DockerComposeインストール
1.最新版のdocker-composeをインストール
- 以下のShellファイルを作成
#!/bin/bash compose_version=$(curl https://api.github.com/repos/docker/compose/releases/latest | jq .name -r) output='/usr/local/bin/docker-compose' sudo curl -L https://github.com/docker/compose/releases/download/$compose_version/docker-compose-$(uname -s)-$(uname -m) -o $output sudo chmod +x $output echo $(docker-compose --version)
2.最新版のdocker-composeをインストール
#「jqコマンド」がインストールされてない場合 $ sudo yum -y install jq #Shellの実行権限を付与 $ chmod 755 docker-compose-install.sh #Shellの実行 $ ./docker-compose-install.sh
3.docker-composeの「実行パス」にシンボリックリンクを付ける。
- この設定だとrootユーザ時に実行する際
フルパス指定での実行になるため
シンボリックリンク
をつける。
#rootユーザで実行時に以下のように「command not found」となる。 $ docker-compose -v bash: docker-compose: command not found #以下のコマンドでシンボリックリンクをつける。 sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose
- シンボリックリンクがついたのかを確認する。
ls -l /usr//bin/docker-compose lrwxrwxrwx. 1 root root 29 May 5 06:41 /usr//bin/docker-compose -> /usr/local/bin/docker-compose
4.docker-composeのインストール確認
- docker-composeのバージョンを確認しインストール有無の確認を行う。
$ docker-compose -v #2020-05-05時点での最新版 docker-compose version 1.25.5, build 8a1c60f6
シンボリックリンクについて
lnコマンドの一覧
-s # シンボリック・リンクを作成する -n # ディレクトリとリンクを置き換える -f # リンク先に同名のリンク・ファイルがあるときも警告なく上書きする
シンボリックリンクの作成
#それぞれのフォルダの間に、半角スペースを忘れずに入れる。 ln -s [シンボリックリンクを作成したいファイルのパス] [シンボリックリンクを置くフォルダのパス]
シンボリックリンクの削除
unlink [シンボリックリンクを置くフォルダのパス]
参考サイト
docker-composeの最新Verでインストール - Qiita
jq コマンドの Linux への速攻インストール - Qiita
Linux環境でdocker-composeのインストール後、docker-composeが失敗するときにすること - Qiita
Dockerセットアップ 第2弾
基本的なDockerのコンテナ作成について
1.DockerHubにログインを行う
- 以下の公式のDockerHubにてアカウントを作成
2.「Docker login」 コマンドにてログイン
- DockerHubで作成したアカウントにてログインを行う
- 以下のコマンドでログインを行う。
docker login
3.DockerHubにてオフィシャルリポジトリからミドルウェアを選択
- DockerHubから「explore」→「ミドルウェアを選択」
#ミドルウェアを選択し以下のコマンドにてイメージをpullする docker pull centos:centos6.7
4.Dockerコンテナの作成
- 以下の
run
コマンドでcentos:6.7
のimageファイル
からコンテナを作成
docker run -i -t centos:6.7 /sbin/init
5.Dockerコンテナの起動と停止
- 以下のコマンドにて
Dockerコンテナ
の起動
と停止
を行う
docker start <コンテナID or NAME> docker stop <コンテナID or NAME>
6.イメージ作成
イメージ作成コマンド
- 以下の利用用途の場合などで
オリジナルのimageファイル
を作成することが出来る。 - 利用用途:オリジナルで
CentOSのイメージなど
を作成した場合など
docker commit <コンテナ名> <作成するDockerイメージ名> #例:imageファイル作成 docker commit WebSocket <DockerHubのユーザ名>:WebSocket
参考サイト
DockerHubへログイン、イメージの取得〜更新、コミットまで。
Dockerセットアップ 第1弾
Dockerのインストール
1.Dockerのインストールの前準備をする。
- 以下のDockerのインストールページを参照にインストールを行う。
1-1.必要なパッケージをインストール
sudo yum install -y yum-utils device-mapper-persistent-data lvm2
1-2.リポジトリ追加
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
1-3.yumのパッケージインデックスを更新
- DockerのINSTALLやUPGRADEの前に一回実行することが推奨されている
sudo yum makecache fast
1-4.インストール可能バージョンを調べる
yum list docker-ce.x86_64 --showduplicates | sort -r
2.Dockerのインストールを行う。
2-1.バージョン指定してインストール
- Dockerをバージョン指定してインストールは以下のコマンドで行う。
$ sudo yum install docker-ce-17.06.0.ce-1.el7.centos
- Dockerの最新バージョンのインストールは以下のコマンドで行う。
sudo yum install docker-ce
2-2.サービス起動
- Deamon化したDockerを以下のコマンドで起動させる。
sudo systemctl start docker.service
2-3.起動確認
- Docker起動の確認が行われたのか、以下のコマンドを実行して確認する。
systemctl status docker #実行結果は以下の通り ● docker.service - Docker Application Container Engine Loaded: loaded #以下省略
3.Dockerのproxy設定
3-1.docker.serviceをコピー
- プロキシサーバを設定している場合
- 以下のファイル
docker.service
をコピーする - コピー場所は
/etc/systemd/system/
のフォルダにコピー
sudo cp /usr/lib/systemd/system/docker.service /etc/systemd/system/
3-2.コピーしたdocker.serviceを開く
- ファイルをコピー後、ファイルを開く
cd /etc/systemd/system/ vi docker.service ## 以下のプロキシ設定を追加 Environment="HTTP_PROXY=http://xx.xxx.xx.xxx:xxxx"
3-3.docker.serviceのExecStartコマンドの直前にProxyの設定を追加
- ファイル
docker.service
のExecStart
コマンドの直前に以下の内容をコピーし保存
## 以下のプロキシ設定を追加 Environment="HTTP_PROXY=http://xx.xxx.xx.xxx:xxxx"
3-4.設定を再読込 & Docker再起動
docker.service
ファイルの設定後、再読込のため 以下のコマンドでデーモンをリロード
し、Dockerを再起動
する。
## デーモンをリロード systemctl daemon-reload ## Dockerを再起動 systemctl restart docker
参考サイト
【iPhoneアプリ】プロパティとは
以前、「【iPhoneアプリ】基本を忘れないように「オブジェクト指向」について」の回で
記載した際に、オブジェクト指向では、 メソッドで「引数に値を代入してクラスの値を更新したり」「クラスの値を取得したり」を 作成し行うと書きました。
そのような機能を「アクセッサメソッド」といいます。
アクセサメソッド「setter(値更新)」「sgetter(値取得)」を自分で記述するのは
非常にめんどくさくて書きたくないです。
そのため、Object-cでは「@property」を利用することにより 「getter」「setter」の記述を省く事が出来 また、以下の要素を持たせる事が可能となります。
アクセス制限
プロパティ属性 | 意味 |
---|---|
readwrite | getter(読込み)/setter(書込み)両方利用可能(デフォルト指定) |
readonly | setter(読込み)のみ可能 |
オブジェクトを代入する際の操作
手動メモリ管理(MRC: Manual Reference Counting)の場合
プロパティ属性 | 意味 |
---|---|
retain | オブジェクトをretain(カウンターを1加算)してから代入 |
assign | オブジェクトをそのまま代入(デフォルト) |
copy | オブジェクトをcopyしてから代入 |
自動メモリ管理(ARC: Automatic Reference Counting)の場合
プロパティ属性 | 意味 |
---|---|
strong | オブジェクトをretain(カウンターを1加算)してから代入 |
weak | オブジェクトをそのまま代入(デフォルト) |
copy | オブジェクトをcopyしてから代入 |
その他
プロパティ属性 | 意味 |
---|---|
unsafe_unretained | オーナーシップ権を持たないプロパティ |
アクセッサメソッド名
プロパティ属性 | 意味 |
---|---|
getter=GETメソッド名 | GETメソッド名の指定 |
setter=SETメソッド名 | SETメソッド名の指定 |
マルチスレッドからのアクセス時の処理
プロパティ属性 | 意味 |
---|---|
atomic | アクセス時に同期処理で処理を行う |
nonatomic | アクセス時に非同期処理で処理を行う |
では、実際にソースを書いて、図でも表現してみます。
Retain(Strong)の説明
- 下記のように「retain」を利用した、propertyを作成します。
//property宣言 データ型_setter,getter名前指定なし @property (nonatomic,retain) NSObject *object_charcter2;
この場合、以下の図のような使われ方となります。
- Retainを使うときはこんな感じです。
- Retainを使い終わった後はこんな感じです。
上記のRetainには下記のようなデメリットもあります。
- デメリットはこんな感じです。
Assign(Weak)の説明
- 下記のように「assign」を利用した、propertyを作成します。
//property宣言 データ型_setter,getter名前指定なし @property (nonatomic,assign) char charcter1;
この場合、以下の図のような使われ方となります。
- Assignを使うときはこんな感じです。
- Assignを使い終わった後はこんな感じです。
Copyの説明
- 下記のように「copy」を利用した、propertyを作成します。
//property宣言 データ型_setter,getter名前指定なし @property (nonatomic,copy) NSObject *object_charcter2;
この場合、以下の図のような使われ方となります。
- Copyを使うときはこんな感じです。
- Copyを使い終わった後はこんな感じです。
上記のCopyには下記のようなメリットもあります。
- メリットはこんな感じです。
MRCとARCの違い
Javaのガーベージコレクションに似ているため、 ガーベージコレクションをイメージして図を作成しております。
MRCの場合このようにメモリを解放します。
ARCの場合このようにメモリーを解放します。
次回は、実装編を記載していきます。