ホストのファイルおよびフォルダをコンテナへコピーする | docker cp

$ docker cp ホスト内のパス コンテナID:コンテナ内のパス
注意:
Windowsである場合、コンテナを停止してから上記コマンドを実行すること。 コンテナが動いている状態だと以下のエラーが表示される。
Error response from daemon: filesystem operations against a running Hyper-V container are not supported

逆にコンテナからホストへ

パスを入れ替えるだけでよい。
$ docker cp コンテナID:コンテナ内のパス ホスト内のパス

Windows環境におけるDockerのLAMP構築(CentOS, PHP, MySQL)

注意
古い方法なので「 docker-compose.yml 環境構築→PHP+Apatche+MySQL 」を推奨。


以下、古い方法。

環境

Windows10 バージョン1903。
Docker Desctop for Windows、2019年11月時点のバージョン
ターミナルはGit Bashを使用。dockerコマンドが使える状態になっていること。

注意!! MySQLの設定は不完全。どうしてもうまくいかない箇所あり。

手順

  1. ターミナルを起動(Git Bash)
  2. Docker HubからCentOS7のイメージをダウンロード
    $ winpty docker pull centos:centos7
    「centos:centos7」の部分は「 centos:latest」でも良い。
  3. $ winpty docker run -it -d --name demo1 -p 8080:80 -v /c:/Users/user/git/docker_demo/html:/var/www/html centos
    winpty winptyはGit for WindowsのGit Bashを使っているときに必要になるコード。これがないとエラーになる。
    -it 「t」の部分はttyを表している。ttyとは仮想環境(コンテナ)の入出力が関わるデバイスのことらしいが詳しくは不明。
    「i」の部分はinteractive、つまり「対話」を表す。シェルなのでコンテナとホスト(仮想でなくいつものWindows)の間で対話できるような仕組みだろうか?
    -d デタッチド・モードする。省略した場合、アタッチモードになる。 デタッチド・モードはコンテナをバックグランドで動かすモードのようだ。 デタッチド・モードにするとターミナル(Git Bash)を閉じてもコンテナは生きており、後ろで動いている。
    --name demo1 --name demo1はコンテナ名を表す。「demo1」の部分に任意の名前を付けられる。
    コンテナ名はdockerの各種コマンドで用いられる。(コンテナ名を省略した場合は、コンテナIDを用いることになる)
    -p 8080:80 「-p 8080:80」はポート番号を表す。
    「80」はwebサーバーを表すおなじみの80番ポートのこと。

    「8080」はホストのブラウザからコンテナのwebサーバーにアクセスするときの仮ポート番号。8080は開発環境を表す慣習的な番号であるが、好きな番号を指定してもよい。 URLに使われており、ホスト側のブラウザで「http://localhost:8080」にアクセスするとコンテナのwebサーバー内のサイトにアクセスできる。
    -v /c:/Users/user/git/docker_demo/html:/var/www/html -vはボリュームのことである。ボリュームとはコンテナ内のディレクトリをホストのディレクトリと結びつける設定のようなもの。(ホストだけでなく別コンテナとの結びつけもできる) コンテナがホストのディレクトリをマウントするという意味合いもある。
    「:」で区切られており、左側がホストのディレクトリ、右側がコンテナ内のディレクトリを表しており、この2つのディレクトリを結び付けている。
    つまり、コンテナ内で「/var/www/html」を見るとき、ホスト内の「c:\Users\user\git\docker_demo」を見ているということである。

    「/c:/Users/user/git/docker_demo/html」はスラッシュから始まっているが、これは「¥」で区切られているということを表しているらしい。 Windows環境ならではの記述方法のようだ。
    centos イメージ名を表す。イメージ名の代わりにイメージIDを指定することもできる。
  4. コンテナが作成されていることを確認する。
    $ docker ps
  5. コンテナ内に入る。
    $ winpty docker attach demo1
    このコマンドを実行するとコンテナ内のCentOSを操作できるようになる。 このことをコンテナにアタッチすると言う。

    コンテナ内の操作から抜けるにはCtrlキーを押しながらP,Qキーと順番に押す。
  6. apacheをコンテナ内のCentOSにインストールする。
    # yum install httpd
    インストール中、いくつか質問を聞かれるのでYES(yを入力)を選択。
  7. apacheを起動する。
    httpd -T

    他のサイトでは「systemctl status httpd.service」でapache起動としている説明が多いが、2020年1月時点ではapacheの起動に失敗する。
    systemctlを使う特権がないのが原因らしい。 systemctlを使えるようにするため、docker runコマンドに「--privileged」を追記する方法もあるが、Windows環境ではこれもバグになる。 現在は「httpd -T」という方法でapacheを起動するようになっているようだ。

    apache起動のエラー Windows環境にてdocker runコマンドに「--privileged」を追記したときのエラー。
  8. ホスト側のブラウザを開き「http://localhost:8080/」のURLにアクセスする。下記のようなページが表示されたら成功。
  9. 続いてボリュームの設定がうまくいっているか確認する。
    docker runの際、ボリュームで指定したホスト側のディレクトリ、「c:/Users/user/git/docker_demo/html」を開き、 「Hello World1」とだけ記述そたtest.htmlを作成し配置する。 ブラウザから「http://localhost:8080/test.html」にアクセス。 test.htmlの内容が表示されたら、ボリュームの設定は成功している。
  10. 続いてMySQLの手順。
    この手順は不完全。
    とりあえずうまくいっている部分を記述。

    イメージをダウンロード
    $ docker pull mysql
    コンテナ作成。
    ポート3306をxamppで仕様しているので、13306にする。(同じ3306を使うとエラーになる)
    $ docker run --name mysql_demo -e MYSQL_ROOT_PASSWORD=neko -d -p 13306:3306 mysql
    実行
    $ winpty docker exec -it mysql_demo bash
    ログイン
    # mysql - h mysql_demo -uroot -pneko

    上手くいっていない箇所

    とりあえず、ここまではうまくいったが,ボリュームによるデータの永続がうまくいかない。
    ↓下記のコマンドをいろいろいじったが、ログインまでは進まず。
    docker run --name mysql_demo -e MYSQL_ROOT_PASSWORD=neko -d -p 13306:3306 mysql -v /mnt/c/Users/user/dbdata:/var/lib/mysql


Docker内のmysqlにアタッチする

$ winpty docker exec -it mysql-51-11 bash
# mysql -u root -p
Enter password:
mysql> show databases;
	

docker-composeでPython環境を構築

まだα版。なんとか動くがまだまだ改良の余地がありそう。
あと前提条件としてDockerとdocker-composeの基礎知識が必要である。

ファイル構成



docker-compose.yml


version: '3'
services:
  app:
    build: ./
    volumes:
      - ./src:/root/src
    tty: true
	

buildはDockerfileを配置しているディレクトリ。 「./」を指定することによりDockerfileは当docker-compose.ymlと同じディレクトリに存在していることを示している。
volumesはPythonのソースコードファイルを配置するディレクトリ。「./src」はホストPC側のsrcディレクトリを指す。 「/root/src」はDockerコンテナ環境におけるディレクトリである。
ttyはとても歴史が古い。デバイスをシリアル接続していたときの名残のようだ。Dockerコンテナをデバイス扱いにしているのだろうか?結局のところよく分からないが重要でもない。

Dockerfile


FROM python:3
USER root

RUN apt-get update
RUN apt-get -y install locales && ¥
    localedef -f UTF-8 -i ja_JP ja_JP.UTF-8
RUN apt-get install -y vim less

ENV LANG ja_JP.UTF-8
ENV LANGUAGE ja_JP:ja
ENV LC_ALL ja_JP.UTF-8
ENV TZ JST-9
ENV TERM xterm

RUN mkdir -p /root/src
COPY ./src /root/src
WORKDIR /root/src

RUN pip install --upgrade pip
	

hello.py


	print ('HelloWorld2')
	print('うさぎとネコの飼い方')
	

コマンド

  1. docker-compose.ymlを配置しているディレクトリへcdコマンドで移動する
  2. インストール&コンテナ起動
    docker-compose up -d
  3. コンテナにアタッチする。(コンテナ内に入る)
    docker exec -it コンテナID bash
    ※コンテナIDは「docker ps」で確認できる。
  4. コンテナにアタッチ後、pythonコマンドを実行できる状態になるので、pythonプログラムを実行する。
    python hello.py


    アタッチ直後におけるコンテナ内のカレントディレクトリは「/root/src」になっている。
    ホストPC側とsrcディレクトリとコンテナ側のsrcディレクトリは常時マウント(接続状態)にある。 なのでホストPC側のsrcディレクトリでPythonのコーディングができる。