Dockerコンテナからのデタッチ

表題の通り。コンテナを稼動させたままデタッチする方法を忘れがちなのでメモとして残しておく。

■ 環境

  • Docker 1.8.2

■ detach

Dockerコンテナで作業をしていて、コンテナから抜けたいが、単に`control-D`で抜けようとすると”logout“になりコンテナは終了してしまう。これを回避する方法である。

[control-P] [control-Q]

上記でコンテナからデタッチすることができる。

以降、下記で起動したコンテナにて実験する。

$ docker run -ti --rm centos:6 /bin/bash

別のターミナルから確認する。

$ docker ps -a
CONTAINER ID  IMAGE     COMMAND      CREATED        STATUS        PORTS  NAMES
18efb83c9f93  centos:6  "/bin/bash"  7 seconds ago  Up 7 seconds         backstabbing_cori
$

コンテナから`control-D`で抜けてみる。

$ docker run -ti --rm centos:6 /bin/bash
[root@18efb83c9f93 /]# exit

`docker ps`で確認すると下記のようにコンテナは停止される。既に削除されているのは、起動時の`–rm`オプションを付与しているからである。

$ docker ps -a
CONTAINER ID  IMAGE   COMMAND   CREATED   STATUS   PORTS   NAMES
$

再度、コンテナを起動し、次はデタッチしてみる。

$ docker run -ti --rm centos:6 /bin/bash
[root@4977948e8cbc /]# [control-P] [control-Q]$

この状態でコンテナ一覧を確認する。

$ docker ps -a
CONTAINER ID  IMAGE     COMMAND      CREATED        STATUS        PORTS  NAMES
4977948e8cbc  centos:6  "/bin/bash"  3 minutes ago  Up 3 minutes         suspicious_khorana
$

デタッチが正常にでき、コンテナは停止&削除されていない。このコンテナに戻るにはアタッチすれば良い。

$ docker attach [ContainerID or ContainerName]

以上。

■ 関連

DockerHubのアカウント作成

表題の通り。自身で作成したDockerコンテナを別の人と共有する為に、DockerHubを利用する事にした。プライベートなレポジトリとしては1コンテナしか利用できない(?)ようであるが、別に機密情報等をDockerコンテナに入れるわけでもないので問題なし。レポジトリ自体が海外にある(?)ようであるが、これもまた頻度が多いわけでもないし少々の時間が掛かっても影響はないので問題なし。

以降、DockerHubのアカウントを作成する手順。

1. DockerHubにアクセス

Docker Hub
https://hub.docker.com/

dockerhub-001

2. 必要事項の入力

username” / “email” / “password” をそれぞれ入力し、”Sign Up“を押す。

dockerhub-002

上図のようにアカウントが作成されれば、登録したアドレスに届いたメールを確認する。

3. メール確認

アドレスを間違えていなければ、下記のようなメールが届いているはずである。

dockerhub-003

Confirm Your Email“を押すと、ブラウザが開かれる。

4. ログイン

登録時に設定した”username“/”password“でログインする。

dockerhub-004

正常にログインができれば下記のようになるはずである。

dockerhub-005

自身の場合には、ログイン時に使用したメールアドレスがGravaterに登録しているものと同じなのでユーザにアイコンが表示されている。

以上。

■ 関連

MavenのDockerコンテナ作成時の注意

表題の通り。基本中の基本なのだろうが、少々ハマってしまったので自戒の為にメモ。

■ 環境

  • Docker 1.8.2
  • CentOS 6.7
  • Maven 3.3.3

■ Dockerコンテナ

CentOS-6.7のDockerイメージを用いて、Maven-3.3.3のコンテナイメージを作成しようとした。JDKをインストールして、Mavenを入れて、さて動かそうと思ったところエラー。

複数versionのJDKをインストールしていた為、環境変数”JAVA_HOME“を設定していなかった。それによって`mvn`コマンド内で`which`コマンドが使用されていたのが原因のようであった。

CentOS-6.7のDockerコンテナでは`which`コマンドがインストールされていないのが原因であった。

Dockerfileにて下記行を追記。

RUN yum install -y which

これによって`mvn`コマンドが正常に稼動してくれるようになった。

[root@CONTAINER /]# mvn -version
Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06; 2015-04-22T20:57:37+09:00)
Maven home: /opt/apache-maven-3.3.3
Java version: 1.8.0_60, vendor: Oracle Corporation
Java home: /usr/java/jdk1.8.0_60/jre
Default locale: en_US, platform encoding: ANSI_X3.4-1968
OS name: "linux", version: "4.0.9-boot2docker", arch: "amd64", family: "unix"
javac 1.8.0_60
[root@CONTAINER /]# 

そもそも”JAVA_HOME“を適切に設定すれば問題ないのであろうと思われる。

以上。

S3にアップロード時のpermission

awscliを使用時において表題の通り。たまに忘れるのでメモ。

■ 環境

  • awscli 1.8.6

■ S3にファイルをアップロード

awscliでファイルをS3にアップロードするとき、下記のようにしている。

$ aws s3 cp ./testfile.txt s3://withsin/testfile.txt

この状態でアップロードされたファイルのアクセス許可(permission)は下記の通り。

s3-permission-001

■ –acl

`aws s3 cp`コマンドには`–acl`オプションがあり、下記を指定することができる。

  • private
  • public-read
  • public-read-write
  • authenticated-read
  • bucket-owner-read
  • bucket-owner-full-control
  • log-delivery-write

ちなみに、その他の文字列を渡すと下記のようにエラーとなる。

$ aws s3 cp ./testfile.txt s3://withsin/testfile.txt --acl log-derivery-write
usage: aws [options]   [parameters]
aws: error: argument --acl: Invalid choice, valid choices are:

private                       | public-read
public-read-write             | authenticated-read
bucket-owner-read             | bucket-owner-full-control
log-delivery-write

Invalid choice: 'log-derivery-write', maybe you meant:

  * log-delivery-write
$

試しに全てを実行してみたが、自身がやりたいことは下記である。

  • URLを知っている人は誰でもダウンロード可能

これはManagementConsoleでは下記のようになるはず。

s3-permission-002

`–acl`オプションを使って実現するには下記。

$ aws s3 cp ./testfile.txt s3://withsin/testfile.txt --acl public-read

ACLに関しての詳細は下記を参照。

アクセスコントロールリスト(ACL)の概要
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/acl-overview.html

以上。

■ 関連

Macのdocker-composeをmigrate

表題の通り。やったメモ。

■ 環境

  • Mac OSX (10.10.5)
  • Homebrew
  • docker-compose 1.3.3

■ update

`brew update`した際に気がついた。正式に(?)”fig“から”docker-compose“になったようである。

$ brew update
  :
==> Renamed Formulae
fig -> docker-compose
$

試しに下記を実行してみると、一覧に”fig“のままなので何かをしなければいけないのか?と思い適当にやってみる。

$ brew list
  :
fig
  :
$

■ upgrade

まずは`brew upgrade`をしてみた。

$ brew upgrade fig
Error: fig was renamed to docker-compose and needs to be migrated.
Please run `brew migrate fig`
$

`migrate`しろとのこと。そういえば、インストール時は”docker-compose“で入れたはずと思い、そちらも試してみる。

$ brew upgrade docker-compose
Error: fig was renamed to docker-compose and needs to be migrated.
Please run `brew migrate fig`
$

同じだったので、素直に`migrate`を実行してみる。

■ migrate

$ brew migrate fig
==> Migrating fig to docker-compose
==> Unlinking fig
Moving to: /usr/local/Cellar/docker-compose
==> Linking docker-compose
Error: An unexpected error occurred during linking
No such file or directory - /usr/local/Cellar/fig
Error: Error occured while migrating.
No such file or directory - /usr/local/Cellar/fig
Backuping...
$

失敗した…。`list`にも”fig“で残っている。`uninstall` → `install` してしまうことにした。

$ brew uninstall fig
Uninstalling /usr/local/Cellar/fig/1.3.3... (375 files, 4.6M)
fig 1.3.2 is still installed.
Remove them all with `brew uninstall --force fig`.
$
$ brew uninstall --force fig
Uninstalling fig... (375 files, 4.6M)
$

一旦全て削除。再度インストールする。

$ brew install docker-compose

docker-machine“にも依存していたので、最新の”docker-machine“もインストールされた。`brew list`にも”docker-compose“と”docker-machine“が並ぶようになり、混乱することがなくなりそうだ。

以上。

■ 関連