docker panamx 설치

client설치

 - To create new Panamax Templates and deploy Templates and Images locally​

$ curl http://download.panamax.io/installer/ubuntu.sh | bash

vagrant 설치 필요

Installing Virtualbox:

$ sudo apt-get install virtualbox

Installing Vagrant:

$ sudo apt-get install vagrant

Common to both

Install and run Panamax!

$ panamax init

dokku 설치

dokku설치

wget https://raw.github.com/progrium/dokku/v0.3.17/bootstrap.sh
sudo DOKKU_TAG=v0.3.17 bash bootstrap.sh

dokku 버전 확인

$ dokku version

/home/dokku/VHOST 해당 파일에 서버 도메인추가

ssh 인증 처리 

클라이언트 에서 키 생성

keygen -t rsa

$ cat ~/.ssh/id_rsa.pub | ssh 54.178.188.117 "sudo sshcommand acl-add dokku 54.178.188.117"

-->해당 명령어로 처리가 안되서 아래와 같이 서버에서 직접 처리 

id_rsa.pub클라이언트 의 키 값을 서버로 이동

cat $HOME/client.pub >> $HOME/.ssh/authorized_keys 해당 키를 권한 부여




cat concall.pub |sshcommand acl-add dokku progrium 해당 키에 대하난 acl-add 처리




git remote add dokku dokku@54.178.188.117:test

git push dokku master

정상 처리 확인

dokku git hook에 대한 내용은 배포된 apps 디렉토리의 hook디렉토리 pre-receive 파일 확인

dokku@apis-dev:~/test123/hooks$ cat pre-receive
#!/usr/bin/env bash
set -e; set -o pipefail;

cat | DOKKU_ROOT="/home/dokku" dokku git-hook test123

git-hook 해당 명령어를 확인하면 docker관련 명령을 통하여 deploy를 진행한다.

dokku 실행 명령어 확인
/var/lib/dokku/plugins/git/commands

docker에서 컨테이너를 종료하지 않고 나오는 방법(bash쉘)

ctrl + p + q
해당 컨테이너를 종료하지 않고 살려놓은 상태로 Host OS로 나올 수 있다.

docker명령어로의 처리는 확인 되지 않아서 현재 상태에서는 모르는 상태이다.

docker 관련 유용한 tools

Panamax
docker의 image나 template를 Web UI에서 손 쉽게 처리 할 수 있도록 처리해주는 tool
컨테이너를 실행하거나 종료 여러개의 컨테이너 처리를 쉽게 할 수 있다.

Shipyard
multi-host, Docker cluster management
docker를 cluster환경을 구성할 수 있도록 처리해주는 tool

Docker Swarm
여러대의 Docker host를 cluster로 묶어서 single docker host 처럼 사용할 수 있게 해주는 tool.

Docker PaaS

Although Docker was a technology originally built out of a PaaS (DotCloud), there have been multiple attempts to create micro-PaaS'es out of Docker.

1. Flynn – https://github.com/flynn 961 stars, 24 forks in Mar 2014 "Flynn is like Sinatra where Cloud Foundry is like Rails"

Flynn is one of the most anticipated Docker PaaS'es right now. With nearly 1,000 stars and dozens of forks, this open-source Docker project has not even been released yet. With a git push deployment to Docker, it is easy to see why there is so much anticipation. Flynn simplifies deploying and maintaining applications. Instead of using complex configuration management systems, Flynn allows self-serve management of containerized deployments, making life easier for ops and developers. Flynn is also different than the other projects on this list because they are a sponsored open-source project. With 14+ sponsors having donated over $80,000, this project is definitely one to watch.

2. Deis – https://github.com/opdemand/deis 1,341 stars, 120 forks in Mar 2014"Your PaaS. Your Rules."

With over 1,300 stars and over 120 forks, Deis is more established than Flynn and also has a git push deploy style. Deis leverages Chef, Docker, Django, Celery, Heroku Buildpacks, and Slugbuilder to do its magic. Deis comes with out-of-the-box support for Ruby, Python, Node.js, Java, Clojure, Scala, Play, PHP, Perl, Dart and Go. Also, Deis can deploy anything using Heroku Buildpacks, Docker images or Chef recipes. Deis can be deployed on any system including every public cloud, private cloud or bare metal. Deis currently supports automated provisioning on EC2, Rackspace and Digital Ocean. In an upcoming blog post, we will compare Deis and Flynn in more detail.

3. Dokku – https://github.com/progrium/dokku 4,806 stars, 384 forks in Mar 2014 "Docker powered mini-Heroku in around 100 lines of Bash"

**If you just want the smallest viable git push to Docker container functionality in the world, take a look at Dokku. From the maker of localtunnel (a super useful utility to reverse-proxy your localhost ports to a public url), this little power-house of an open-source project has the most eye-balls. It is not as feature rich as Deis or Flynn, but it is incredibly easy to install and use on Ubuntu 13 or 12.04 x64.

$ wget -qO- https://raw.github.com/progrium/dokku/v0.2.2/bootstrap.sh | sudo DOKKU_TAG=v0.2.2 bash

Note: Users on 12.04 will need to run apt-get install -y python-software-properties before bootstrapping stable.

Docker Orchestration

4. CoreOS – https://github.com/coreos 2,564 stars, 237 forks in Mar 2014"CoreOS enables warehouse-scale computing on top of a minimal, modern operating system."

**CoreOS is developing best practices for deploying containerized applications to production. It is not a single open-source repository, but rather a collection of many open-source tools that can be used together including etcd, docker, andsystemd. We have written about generating CoreOS files from Fig files before because getting started with CoreOS can be a daunting experience. The etcdlibrary is used as a universal key/value store to stitch services together and share service credentials across an entire application. Unlike many of the other projects in this list, CoreOS is both an open-source project and a venture backed startup (which is why CoreOS is also listed in our Top 10 Startups Built on Docker post).

5. Fig – https://github.com/orchardup/fig 1,526 stars, 51 forks in Mar 2014"Fast, isolated development environments using Docker"

**I have written a few times about Fig because it is one of my favorite little utilities for Docker (Auto-Loadbalancing Docker with Fig, HAProxy and Serf andBuilding Complex Apps for Docker on CoreOS and Fig). Fig lets you write a simple fig.yml file that lists all the Docker containers your app needs and how they should link together. Once you write the fig.yml you just fig up -d and your app will be up and running. This blog is managed by fig right now.

6. Serf – https://github.com/hashicorp/serf 1,652 stars, 91 forks in Mar 2014 "A decentralized solution for service discovery and orchestration that is lightweight, highly available, and fault tolerant"

**Although Serf is not Docker specific, it is like jelly to Docker's peanut butter. Serf is one of my favorite new open-source projects and came from the guys who make Vagrant. I wrote about it a few weeks ago in Decentralizing Docker: How to Use Serf with Docker so you can get a great insight into how to use it with Docker there, but essentially it is a hammer you can use where CoreOS and etcd is a nail-gun. Serf is also really easy to use outside of Docker and can be used in a lot of different ways where etcd and CoreOS are pretty specific tools that aren't nearly as flexible (though definitely very powerful).

CI/CD

7. Drone – https://github.com/drone/drone 2,516 stars, 133 forks in Mar 2014"A Continuous Integration platform built on Docker"

Drone (another project that is both an open source project and a startup) gives you a simple go binary, distributed in a debian file, that gives you a full CI/CD pipeline hooked natively into Docker. Cool, right? Your code never needs to leave your laptop or your company's network to be tested, which is a huge deal for big company developers who have policies that prevent them from using public hosted services like GitHub and Travis. The other cool part of Drone is that you can deploy the fully tested containers into production and be assured that the exact same environment is used in both locations. Finally, Drone lets you build custom Docker containers with whatever custom binaries and configuration you need, which is way more flexible than most CI platforms today.

UI

8. Shipyard – https://github.com/shipyard/shipyard 1,443 stars, 96 forks in Mar 2014 "Open Source Docker Management"

Shipyard gives you the ability to manage Docker resources including containers, images, hosts, and more all from a single management interface including: Multi-Host Support, Container Metrics, and a RESTful API. I love this part, to deploy Shipyard, you just run:

$ docker run -i -t -v /var/run/docker.sock:/docker.sock shipyard/deploy setup

Then you should be able to login to http://localhost:8000 and get the pretty UI (more QuickStart docs available). Slick! Being able to visually see all your containers is killer and Shipyard is a great way to do that.

Orchestration

9. Kubernetes – https://github.com/GoogleCloudPlatform/kubernetes 3,598stars, 501 forks in Sept 2014 "Google's Docker Orchestrator"

Kubernetes is an open source implementation of container cluster management. In other words, it is a system for managing containerized applications across multiple hosts, providing basic mechanisms for deployment, maintenance, and scaling of applications. Its APIs are intended to serve as the foundation for an open ecosystem of tools, automation systems, and higher-level API layers.

10. Panamax – https://github.com/centurylinklabs/panamax-ui 510 stars, 43forks in Sept 2014 "Docker Management for Humans"

Panamax is a containerized app creator with an open-source app marketplace hosted in GitHub. Panamax provides a friendly interface for users of Docker, Fleet & CoreOS. With Panamax, you can easily create, share and deploy any containerized app no matter how complex it might be.

Dockerfile 명령어 정리

1.1    Dockerfile

Dockerfile은 Docker 이미지 설정 파일입니다. Dockerfile에 설정된 내용대로 이미지를 생성합니다.

여러가지 명령을 토대로 기본 이미지에서 개발환경을 셋팅한 이미지를 생성할 수 있습니다.

1.1.1     FROM

FROM은 어떤 이미지를 기반으로 이미지를 생성할지 설정합니다. Dockerfile로 이미지를 생성할 때는 항상 기존에 있는 이미지를 기반으로 생성하기 때문에 FROM은 반드시 설정해야 합니다.

다음과 같이 이미지 이름을 설정하거나 이미지 이름과 태그를 함께 설정할 수도 있습니다. 이미지 이름만 설정하면 latest를 사용합니다. 또한, 이미지 이름은 생략할 수 없습니다.

FROM ubuntu:14.04

FROM <이미지> 또는 FROM <이미지>:<태그> 형식입니다.

앞에서 설명한 것처럼 FROM은 항상 설정해야 하고 맨 처음에 와야 합니다. 이미지를 생성할 때 FROM에 설정한 이미지가 로컬에 있으면 바로 사용하고, 없으면 Docker Hub에서 받아옵니다.

Dockerfile 파일 하나에 FROM을 여러 개 설정할 수 있습니다. FROM을 두 개 설정했다면 이미지가 두 개 생성됩니다. --tag 옵션으로 이미지 이름을 설정했다면 맨 마지막 FROM에 적용됩니다.

1.1.2     MAINTAINER

MAINTAINER는 이미지를 생성한 사람의 정보를 설정합니다. 형식은 자유이며 보통 다음과 같이 이름과 이메일을 입력합니다.

Dockerfile MAINTAINER    Hong, Gildong <gd@yuldo.com>

MAINTAINER <작성자 정보> 형식입니다. MAINTAINER는 생략할 수 있습니다.

1.1.3     RUN

RUN은 FROM에서 설정한 이미지 위에서 스크립트 혹은 명령을 실행합니다. 여기서 RUN으로 실행한 결과가 새 이미지로 생성되고, 실행 내역은 이미지의 히스토리에 기록됩니다.

셸(/bin/sh)로 명령 실행하기

Dockerfile

RUN apt-get install -y nginx RUN echo "Hello Docker" > /tmp/hello RUN curl -sSL https://golang.org/dl/go1.3.1.src.tar.gz | tar -v -C /usr/local -xz RUN git clone https://github.com/docker/docker.git

RUN <명령> 형식이며 셸 스크립트 구문을 사용할 수 있습니다. FROM으로 설정한 이미지에 포함된 /bin/sh 실행 파일을 사용하게 되며 /bin/sh 실행 파일이 없으면 사용할 수 없습니다.

셸 없이 바로 실행하기

Dockerfile

RUN ["apt-get", "install", "-y", "nginx"] RUN ["/user/local/bin/hello", "--help"]

RUN ["<실행 파일>", "<매개 변수1>", "<매개 변수2>"] 형식입니다. 실행 파일과 매개 변수를 배열 형태로 설정합니다. FROM으로 설정한 이미지의 /bin/sh 실행 파일을 사용하지 않는 방식입니다. 셸 스크립트 문법이 인식되지 않으므로 셸 스크립트 문법과 관련된 문자를 그대로 실행 파일에 넘겨줄 수 있습니다.

RUN으로 실행한 결과는 캐시되며 다음 빌드 때 재사용합니다. 캐시된 결과를 사용하지 않으려면 docker build 명령에서 --no-cache 옵션을 사용하면 됩니다.

1.1.4     CMD

CMD는 컨테이너가 시작되었을 때 스크립트 혹은 명령을 실행합니다. 즉 docker run 명령으로 컨테이너를 생성하거나, docker start 명령으로 정지된 컨테이너를 시작할 때 실행됩니다. CMD는 Dockerfile에서 한 번만 사용할 수 있습니다.

셸(/bin/sh)로 명령 실행하기

Dockerfile

CMD touch /home/hello/hello.txt

CMD <명령> 형식이며 셸 스크립트 구문을 사용할 수 있습니다. FROM으로 설정한 이미지에 포함된 /bin/sh 실행 파일을 사용하게 되며 /bin/sh 실행 파일이 없으면 사용할 수 없습니다.

셸 없이 바로 실행하기

Dockerfile

CMD ["redis-server"]

셸 없이 바로 실행할 때 매개 변수 설정하기

Dockerfile

CMD ["mysqld", "--datadir=/var/lib/mysql", "--user=mysql"]

CMD ["<실행 파일>", "<매개 변수1>", "<매개 변수2>"] 형식입니다. 실행 파일과 매개 변수를 배열 형태로 설정합니다. FROM으로 설정한 이미지의 /bin/sh 실행 파일을 사용하지 않는 방식입니다. 셸 스크립트 문법이 인식되지 않으므로 셸 스크립트 문법과 관련된 문자를 그대로 실행 파일에 넘겨줄 수 있습니다.

ENTRYPOINT를 사용하였을 때

Dockerfile

ENTRYPOINT ["echo"] CMD ["hello"]

CMD ["<매개 변수1>", "<매개 변수2>"] 형식입니다. ENTRYPOINT에 설정한 명령에 매개 변수를 전달하여 실행합니다. Dockerfile에 ENTRYPOINT가 있으면 CMD는 ENTRYPOINT에 매개 변수만 전달하는 역할을 합니다. 그래서 CMD 독자적으로 파일을 실행할 수 없게 됩니다.

1.1.5     EXPOSE

EXPOSE는 호스트와 연결할 포트 번호를 설정합니다. docker run 명령의 --expose 옵션과 동일합니다.

Dockerfile

EXPOSE 80 EXPOSE 443 EXPOSE 80 443

EXPOSE <포트 번호> 형식입니다. EXPOSE 하나로 포트 번호를 두 개 이상 동시에 설정할 수도 있습니다.

EXPOSE는 호스트와 연결만 할 뿐 외부에 노출은 되지 않습니다. 포트를 외부에 노출하려면 docker run 명령의 -p, -P 옵션을 사용해야 합니다.

1.1.6     WORKDIR

RUN, CMD and ENTRYPOINT에서 설정한 실행 파일이 실행될 디렉터리입니다.

WORKDIR /path/to/workdir

1.1.7     ENV

ENV는 환경 변수를 설정합니다. ENV로 설정한 환경 변수는 RUN, CMD, ENTRYPOINT에 적용됩니다.

Dockerfile

ENV GOPATH /go ENV PATH /go/bin:$PATH

ENV <환경 변수> <값> 형식입니다. 환경 변수를 사용할 때는 $를 사용하면 됩니다.

환경 변수는 docker run 명령에서도 설정할 수 있습니다.

$ sudo docker run -e HELLO=4321 example 4321

-e <환경 변수>=<값> 형식입니다. -e 옵션은 여러 번 사용할 수 있고, --env 옵션과 같습니다.

1.1.8     ADD

ADD는 파일을 이미지에 추가합니다.

Dockerfile

ADD hello-entrypoint.sh /entrypoint.sh ADD http://example.com/hello.txt /hello.txt ADD *.txt /root/

ADD <복사할 파일 경로> <이미지에서 파일이 위치할 경로> 형식입니다.

<복사할 파일 경로>는 컨텍스트 아래를 기준으로 하며 컨텍스트 바깥의 파일, 디렉터리나 절대 경로는 사용할 수 없습니다.

예) ADD ../hello.txt /home/hello (X)

예) ADD /home/hello/hello.txt /home/hello (X)

<복사할 파일 경로>는 파일뿐만 아니라 디렉터리도 설정할 수 있으며, 디렉터리를 지정하면 디렉터리의 모든 파일을 복사합니다. 또한, 와일드카드를 사용하여 특정 파일만 복사할 수 있습니다.

예) ADD *.txt /root/

<복사할 파일 경로>에 인터넷에 있는 파일의 URL을 설정할 수 있습니다.

<이미지에서 파일이 위치할 경로>의 마지막에 /가 있으면 디렉터리가 생성되고 파일은 그 아래에 복사됩니다. ADD http://example.com/hello.txt /home/hello/ 와 같이 설정하면 /home/hello/hello.txt에 파일이 복사됩니다.

로컬에 있는 압축 파일(tar.gz, tar.bz2, tar.xz)은 압축을 해제하고 tar를 풀어서 추가됩니다. 단, 인터넷에 있는 파일 URL은 압축만 해제한 뒤 tar 파일이 그대로 추가됩니다.

예) ADD hello.tar.gz / (압축을 해제하고 tar를 풀어서 추가합니다.)

예) ADD http://zlib.net/zlib-1.2.8.tar.gz / (gzip 압축만 해제한 뒤 tar 파일을 추가합니다. 단 파일 내용은 tar이지만 파일 이름은 zlib-1.2.8.tar.gz처럼 .gz가 붙어있습니다.)

<이미지에서 파일이 위치할 경로>는 항상 절대 경로로 설정해야 합니다. 그리고 마지막이 /로 끝나면 디렉터리가 생성되고 파일은 그 아래에 복사됩니다.

ADD ./ /hello와 같이 현재 디렉터리를 추가할 때 .dockerignore 파일에 설정한 파일과 디렉터리는 제외됩니다.

ADD로 추가되는 파일은 소유자(UID) 0, 그룹(GID) 0으로 설정되고 권한은 기존 파일의 권한을 따릅니다. URL로 추가하면 권한은 600으로 설정됩니다.

1.1.9     COPY

COPY는 파일을 이미지에 추가합니다. ADD와는 달리 COPY는 압축 파일을 추가할 때 압축을 해제하지 않고, 파일 URL도 사용할 수 없습니다.

Dockerfile

COPY hello-entrypoint.sh /entrypoint.sh COPY hello-dir /hello-dir COPY zlib-1.2.8.tar.gz /zlib-1.2.8.tar.gz COPY *.txt /root/

COPY <복사할 파일 경로> <이미지에서 파일이 위치할 경로> 형식입니다.

<복사할 파일 경로>는 컨텍스트 아래를 기준으로 하며 컨텍스트 바깥의 파일, 디렉터리나, 절대 경로는 사용할 수 없습니다.

예) COPY ../hello.txt /home/hello (X)

예) COPY /home/hello/hello.txt /home/hello (X)

<복사할 파일 경로>는 파일뿐만 아니라 디렉터리도 설정할 수 있으며, 디렉터리를 지정하면 디렉터리의 모든 파일을 복사합니다. 또한, 와일드카드를 사용하여 특정 파일만 복사할 수 있습니다.

예) COPY *.txt /root/

<복사할 파일 경로>에 인터넷에 있는 파일의 URL은 사용할 수 없습니다.

압축 파일은 압축을 해제하지 않고 그대로 복사됩니다.

<이미지에서 파일이 위치할 경로>는 항상 절대 경로로 설정해야 합니다. 그리고 마지막이 /로 끝나면 디렉터리가 생성되고 파일은 그 아래에 복사됩니다.

COPY ./ /hello와 같이 현재 디렉터리를 추가할 때 .dockerignore 파일에 설정한 파일과 디렉터리는 제외됩니다.

COPY로 추가되는 파일은 소유자(UID) 0, 그룹(GID) 0으로 설정되고 권한은 기존 파일의 권한을 따릅니다.

1.1.10  ENTRYPOINT

ENTRYPOINT는 컨테이너가 시작되었을 때 스크립트 혹은 명령을 실행합니다. 즉 docker run 명령으로 컨테이너를 생성하거나, docker start 명령으로 정지된 컨테이너를 시작할 때 실행됩니다. ENTRYPOINT는 Dockerfile에서 단 한번만 사용할 수 있습니다

CMD와 ENTRYPOINT는 컨테이너가 생성될 때 명령이 실행되는 것은 동일하지만 docker run 명령에서 동작 방식이 다릅니다.

run <이미지> <실행할 파일> 형식인데 이미지 다음에 실행할 파일을 설정할 수 있습니다. docker run 명령에서 실행할 파일을 설정하면 CMD는 무시됩니다.

1.1.11  VOLUME

VOLUME은 디렉터리의 내용을 컨테이너에 저장하지 않고 호스트에 저장하도록 설정합니다. 6.4 Docker 데이터 볼륨 사용하기에서 설명한 내용과 같습니다.

Dockerfile

VOLUME /data VOLUME ["/data", "/var/log/hello"]

VOLUME <컨테이너 디렉터리> 또는 VOLUME ["컨테이너 디렉터리 1", "컨테이너 디렉터리2"] 형식입니다. /data처럼 바로 경로를 설정할 수도 있고, [“/data”, “/var/log/hello”]처럼 배열 형태로 설정할 수도 있습니다. 단, VOLUME으로는 호스트의 특정 디렉터리와 연결할 수는 없습니다.

데이터 볼륨을 호스트의 특정 디렉터리와 연결하려면 docker run 명령에서 -v 옵션을 사용해야 합니다.

$ sudo docker run -v /root/data:/data example

옵션은 -v <호스트 디렉터리>:<컨테이너 디렉터리> 형식입니다.

1.1.12  USER

USER는 명령을 실행할 사용자 계정을 설정합니다. RUN, CMD, ENTRYPOINT에 적용됩니다.

USER nobody

USER <계정 사용자명> 형식입니다.

USER 뒤에 오는 모든 RUN, CMD, ENTRYPOINT에 적용되며, 중간에 다른 사용자를 설정하여 사용자를 바꿀 수 있습니다.

1.1.13  ONBUILD

ONBUILD는 생성한 이미지를 기반으로 다른 이미지가 생성될 때 명령을 실행(trigger)합니다. 최초에 ONBUILD를 사용한 상태에서는 아무 명령도 실행하지 않습니다. 다음 번에 이미지가 FROM으로 사용될 때 실행할 명령을 예약하는 기능이라 할 수 있습니다.

Dockerfile

ONBUILD RUN touch /hello.txt ONBUILD ADD world.txt /world.txt

ONBUILD <Dockerfile 명령> <Dockerfile 명령의 매개 변수> 형식입니다. FROM, MAINTAINER, ONBUILD를 제외한 모든 Dockerfile 명령을 사용할 수 있습니다.

ONBUILD는 이미지를 생성한 뒤 해당 이미지를 기반으로 커스터마이징을 할 때 활용할 수 있습니다.

다음과 같이 ONBUILD를 사용하여 RUN touch /hello.txt를 실행하도록 설정합니다.

Dockerfile

FROM ubuntu:latest ONBUILD RUN touch /hello.txt

docker build 명령으로 example 이미지를 생성한 뒤 docker run 명령으로 컨테이너를 생성합니다. 컨테이너의 Bash 셸이 실행되면 ls 명령으로 /의 파일 목록을 출력합니다.

$ sudo docker build --tag example . $ sudo docker run -i -t example /bin/bash root@891ccb6749e9:/# ls bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

ONBUILD로 설정했기 때문에 example 이미지에는 /hello.txt 파일이 생성되지 않았습니다.

이제 FROM을 사용하여 example 이미지를 기반으로 새 이미지를 생성합니다.

Dockerfile

FROM example

docker build 명령으로 example2 이미지를 생성한 뒤 docker run 명령으로 컨테이너를 생성합니다. 컨테이너의 Bash 셸이 실행되면 ls 명령으로 /의 파일 목록을 출력합니다.

$ sudo docker build --tag example2 . …생략 root@874d3e1fdd6f:/# ls bin  boot  dev  etc  hello.txt  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

docker build 명령을 실행할 때 # Executing 1 build triggers라고 출력되고 그 아래부터 ONBUILD로 설정한 명령이 실행됩니다. 이제 ONBUILD를 통해 example2 이미지에 /hello.txt 파일이 생성되었습니다.

ONBUILD는 바로 아래 자식 이미지를 생성할 때만 적용되고, 손자 이미지에는 적용되지 않습니다. 즉 ONBUILD 설정은 상속되지 않습니다.

참조 - 이재홍(http://pyrasis.com/book/DockerForTheReallyImpatient/Chapter04/02)