[태그:] docker

Docker private registry 간편 설정 KOPS

이 전 글에서 kubernetes 에 docker private registry 를 사용하는 방법 에 대해 기술 했습니다.

하지만 막상 사용하다보면 매번 imagePullSecrets 을 입력해줘야하는 불편함이 있습니다.

해서 각 노드마다 docker.json 을 배포해주면 되지 않을까 싶어서 찾아보다보니 kops 에서 자체적으로 지원합니다.

kops/security.md at master · kubernetes/kops · GitHub

위 링크를 가면 아래와 같은 방법이 나옵니다만…

kops create secret --name <clustername> dockerconfig -f ~/.docker/config.json
kops rolling-update cluster --name <clustername> --yes

제 현재 상황에서는 rolling-update 를 실행해도 변화된것이 없다고 적용이 되지 않더군요.

현재 버전

KOPS Version: 1.10.0 (git-8b52ea6d1)
kubernetesVersion: 1.10.6

방법은 간단합니다. 강제로 rolling-update를 수행하면 됩니다.

kops rolling-update cluster --name <clustername> --yes --force

이제 손쉽게 docker private registry를 사용할 수 있습니다.

Kubernetes + private docker registry

kubernetes 설정이 완료 되었으면, 이제 실제로 kubernetes 를 사용하기 위한 docker registry 연동 설정을 해보겠습니다.

보통 회사에서 사용할 때는 자체 private docker registry 를 사용하고 있을 겁니다.

이 registry 를 kubectl 을 이용해서 연동해봅시다.

Set up Docker Registry

Pull an Image from a Private Registry – Kubernetes
위 글을 참고 하여 연동을 합니다.

등록

Usage:

kubectl create secret docker-registry NAME –docker-username=user –docker-password=password –docker-email=email [–docker-server=string] [–from-literal=key1=value1] [–dry-run] [options]

kubectl create secret docker-registry regcred --docker-server=https://example.com --docker-username=aws --docker-password="abcd1234" --docker-email="aws@example.com"

Docker-registry secret 이름을 여기서는 regcred로 생성해서 만들었습니다.

확인

kubectl get secret regcred --output=yaml

Output:

apiVersion: v1
data:
  .dockerconfigjson: eyJhdXRocyI6eyJodH3FovL2RyZWcuYcyI6eyJodH3FovMiLCJwYXNzd29yZCI6ImdyYWNlbm90ZTEyIUAiLC3D2KWFpbCI6ImF3c0BncmFjZW5vdGUuY29tIiwiYXV0aCI6IllYZHpPbWR5WVdObGJcyI6eyJodH3FovJ9fX0=
kind: Secret
metadata:
  creationTimestamp: 2018-07-11T06:15:56Z
  name: regcred
  namespace: default
  resourceVersion: "6036405"
  selfLink: /api/v1/namespaces/default/secrets/regcred
  uid: df5d178b-84d1-11e8-b74a-0e9d5423172c
type: kubernetes.io/dockerconfigjson

출력 결과에서 .dockerconfigjosn이라는 내용은 실제 docker registry 접속정보를 나타냅니다. 아래 명령을 통해 정상적으로 접속정보가 들어갔는지 확인 해 볼 수 있습니다. 

kubectl get secret regcred --output="jsonpath={.data.\.dockerconfigjson}" | base64 -d

맥북일 경우는 -d 옵션을 대문자  -D 로 변경합니다.  

kubectl get secret regcred --output="jsonpath={.data.\.dockerconfigjson}" | base64 -D

Output:

{"auths":{"https://example.com":{"username":"aws","password":"abcd1234","email":"aws@example.com","auth":"YxDAOmdyKZNlbm30ZTEyIUA="}}}

TEST

이제 설정은 완료됐습니다.
실제 pod 를 배포해서 정상적으로 동작하는지 TEST 해 봅시다. 

apiVersion: v1
kind: Pod
metadata:
  name: private-reg
spec:
  containers:
  - name: private-reg-container-nginx
    image: example.be/devops/nginx-custom:0.1.0
  imagePullSecrets:
  - name: regcred

위의 내용으로 my-private-reg-pod.yml 파일을 생성합니다.

kubectl create -f my-private-reg-pod.yml

위 명령 실행후 정상적으로 pod 생성이 되는지 확인합니다. 

kubectl get po private-reg

Output:

 ✘ ktg@dev-vm-of00-016  ~/projects/k8s kubectl get po private-reg
NAME                            READY     STATUS    RESTARTS   AGE
private-reg                     1/1       Running   0          1m

STATUS 가 Running 이면 정상동작하는 것을 알수 있습니다.

curl로 nginx 작동 여부를 확인하고 싶다면, 

kubectl exec -it private-reg (bash or sh)
curl localhost

위 명령을 실행 하면 됩니다.

RoR (rails) Dockerfile tip

RoR (rails) Dockerfile tip

루비 온 레일즈 (Ruby on Rails)를 Docker 로 배포할 때 간단 팁입니다.

Rails 를 도커로 배포할 때 가장 큰 문제는 Rebuild 시간이 오래걸린다는 것입니다.

원인은 바로 bundler !!

$ bundle install

이놈이 오래걸립니다.

하여 예전에 이 Article 을 보고 적용해서 쓰던 중 보다 괜찮은 방법이 있어서 기록합니다.

Prerequisite

  • ruby 2.3.4
  • Rails 5.1.2
  • docker 17.06-ce

Rails on Docker

제가 쓰는 Dockerfile 을 아래 공유합니다.

FROM ruby:2.3.4-slim
LABEL maintainer="9to5, ktk0011+dev@gmail.com"

RUN apt-get update && \
    apt-get install -y --no-install-recommends \
    build-essential git libpq-dev nodejs vim libxslt-dev libxml2-dev cron && \
    rm -rf /var/lib/apt/lists/*

ENV INSTALL_PATH /app
WORKDIR $INSTALL_PATH

ENV BUNDLE_FROZEN=1 BUNDLE_DISABLE_SHARED_GEMS=true BUNDLE_WITHOUT=development:test

ADD ./bin $INSTALL_PATH/bin
COPY Gemfile Gemfile.lock ./
RUN bin/bundle install --deployment

ADD . $INSTALL_PATH

기존과의 차이점은 BUNDLE_FROZEN 을 이용해서 더이상 Gem변경을 허용하지 않으며,
BUNDLE_DISABLE_SHARED_GEMS 설정으로 번들 path를 고정하고,

BUNDLE_WITHOUT 을 이용해서 오직 deployment 환경을 대상으로만 bundle 을 관리합니다.

Conclusion

이런 형태로 사용한다면 docker 로 변경된 내용을 배포할 때 마다 bundler 때문에 시간이 소모되는 문제를 쉽게 해결 가능합니다.

Docker machine for Mac 에서 no space left on device

Docker machine for Mac 에서 no space left on device

오늘은 Docker를 Mac에서 사용할 때 격는 문제에 대해 정리합니다.

 

Prerequisite

  • Docker version 17.03.1-ce
  • Docker-machine version 0.10.0

 

저는 Docker toolbox 를 이용하고 있으며, Docker for Mac 과 의 차이점에 관련된 내용은 여기서 참고하시면 됩니다.

Problem

Docker 이미지 빌드 중에 이런 메시지를 만났습니다.

failed to register layer: Untar re-exec error: exit status 1: output: write /home/oracle/app/oracle/oradata/oracle/users01.dbf: no space left on device

no space left on device

틀림없이 제 맥북은 용량이 많이 남아있습니다.

Solution

Docker-machine 은 VirtualBox 를 이용해서 docker를 실행합니다.
이에 docker가 실행되는 환경 접속을 하려면 별도의 명령이 필요합니다.

$ docker-machine ssh

이제 도커가 돌고 있는 가상 환경으로 들어왔습니다.

디스크 용량을 확인합니다.

$ sudo df -h

...
/dev/sda1 20.0G 19.9G 0.1G 99% /mnt/sda1/var/lib/docker/aufs
...

저 녀석이 꽉차 있습니다.

그냥 docker-machine의 가상머신 환경을 날리고 용량을 크게 다시 만듭니다.

$ docker-machine ls

NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS
default * virtualbox Running tcp://192.168.99.101:2376 v17.06.0-ce

저 default를 날립니다.

$ docker-machine rm default

이제 disk size 를 새로 지정합니다. 여기서는 80G 로 만듭니다.

$ docker-machine create --driver virtualbox --virtualbox-disk-size "80000" default

이 전 과정을 반복해서 용량을 확인합니다.

$ docker-machine ssh
$ sudo df -h

변경이 완료되었습니다.

iwinv(가상호스팅)에 docker 적용하기

iwinv(가상호스팅)에 docker 적용하기

iwinv 제가 호스팅을 이전했다는 사실은 지난 글에서 이미 언급한 적이 있습니다.

오늘은 iwinv 로 이전하면서 엄청난 고생을 했던 경험에 대한 이야기 및 해결책에 대한 이야기를 적어 보려 합니다.

Environment

  • Ubuntu 16.04 xenial

삽질의 시작

IwinV Manual

iwinv 홈페이지를 가면 이렇게 도커 적용을 하는 것에 대한 매뉴얼이 있습니다만…

가격의 매리트와 docker 적용에 대한 호기심으로 시작한 이 작업이 이렇게 크나큰 고통을 안겨 줄 것이라는 것을 이 때는 몰랐습니다.

사실 저 메뉴얼이 있는걸 확인 하고 docker 적용에 별 어려움이 없을 것이라고 판단했던 것이 제가 서버 이전을 마음 먹은 것에 큰 이유 중 하나이기도 합니다.
물론 iwinv의 메뉴얼은 저를 속였습니다. (물론 회사가 의도친 않았지만…)ㅎㅎㅎ

이유인 즉, 저 매뉴얼은 반 쪽짜리 매뉴얼 이었기 때문입니다.

물론 간단히 하나의 도커파일만으로 사용할 경우는 별 문제가 없을 지도 모르겠습니다만,
도커 이미지간에 네트웍 통신에는 치명적 문제가 있었습니다.

MTU

위의 매뉴얼 링크를 클릭해보시면 아시겠지만, iwinv는 내부적으로 MTU를 1450으로 사용하고 있다고 합니다. 이리하여 도커의 MTU 설정을 변경해줘야 한다는 것이 저 글의 요지입니다.

자, 그럼 MTU가 무엇이냐하면,

컴퓨터 네트워킹에서, 레이어의 커뮤니케이션 프로토콜의 최대 전송 단위(maximum transmission unit, MTU)란 해당 레이어가 전송할 수 있는 최대 프로토콜 데이터 단위의 크기(바이트)이다.

최대 전송 단위 – 위키백과, 우리 모두의 백과사전

간단히 말해 네트워크 통신에서의 패킷 사이즈를 결정하는 단위라고 생각하면 될 듯 합니다.

이때는 “아 패킷 사이즈를 iwinv가 적게 쓰는 구나.” 하고 넘어갔습니다.

Docker 설치

매뉴얼대로 도커를 설치합니다.
물론 이 포스팅에서는 매뉴얼과 docker 홈페이지를 적절히 이용해서 설치하겠습니다.
현 시점에서의 설치방법입니다. (2017.6)

먼저 apt-get 업데이트를 합니다.

$ sudo apt-get update
$ sudo apt-get upgrade

도커 설치는 공식페이지를 참고합니다.

오래된 버전의 docker 가 있다면 지웁니다.

$ sudo apt-get remove docker docker-engine

docker 설치에 필요한 패키지를 설치합니다.

$ sudo apt-get install \
apt-transport-https \
ca-certificates \
curl \
software-properties-common

docker 의 공식 GPG key를 추가합니다.

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

키를 확인합니다.
9DC8 5822 9FC7 DD38 854A E2D8 8D81 803C 0EBF CD88

$ sudo apt-key fingerprint 0EBFCD88

pub 4096R/0EBFCD88 2017-02-22
Key fingerprint = 9DC8 5822 9FC7 DD38 854A E2D8 8D81 803C 0EBF CD88
uid Docker Release (CE deb) <docker@docker.com>
sub 4096R/F273FCD8 2017-02-22

amd64 architecture 를 사용하는 docker 를 설치하겠습니다.

$ sudo add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"

Docker 가 설치가 잘 되었는지 확인

$ sudo docker run hello-world

...
Hello from Docker!
This message shows that your installation appears to be working correctly.

여기서부터 iwinv의 메뉴얼을 따릅니다.

$ sudo docker pull ubuntu
$ sudo docker run -it ubuntu

※ update가 진행이 안되는 문제 발생하며 ftp 등 일부 서비스에서 문제 발생.

위 증상은 MTU 때문입니다.
이제 MTU를 1450으로 세팅합니다.

$ cp /lib/systemd/system/docker.service /etc/systemd/system/docker.service
$ vi /etc/systemd/system/docker.service

/etc/systemd/system/docker.service

[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network.target docker.socket firewalld.service
Requires=docker.socket

[Service]
Type=notify
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
ExecStart=/usr/bin/dockerd -H fd:// --mtu=1450
#-H fd://
ExecReload=/bin/kill -s HUP $MAINPID
LimitNOFILE=1048576
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNPROC=infinity
LimitCORE=infinity
# Uncomment TasksMax if your systemd version supports it.
# Only systemd 226 and above support this version.
TasksMax=infinity
TimeoutStartSec=0
# set delegate yes so that systemd does not reset the cgroups of docker containers
Delegate=yes
# kill only the docker process, not all processes in the cgroup
KillMode=process

[Install]
WantedBy=multi-user.target

ExecStart=/usr/bin/dockerd -H fd:// —mtu=1450

이렇게 변경 후에 아래 명령 실행합니다.

$ sudo systemctl daemon-reload
$ sudo service docker restart

이제 이 전의 명령을 다시 실행해봅니다.

$ sudo docker run -it ubuntu

진행이 정상적으로 되는 것을 확인 할 수 있습니다.

Docker compose

여기까지 설치했다면 iwinv의 메뉴얼 대로 잘 설치된 상황입니다.

허나 함정이 있습니다.
바로 docker-compose를 사용하게 될 때의 문제인데요.

먼저 docker-compose를 알아봅시다.

docker compose 란 간단히 말해서 docker application을 이용한 서비스 환경 구축을 손쉽게 도와주는 tool 이라고 생각하시면 됩니다.

일반적으로 web service 구축을 위해선 web application 과 database 가 필요할 것입니다.
docker compose 는 이 둘을 한번에 구성하기 위한 툴로 보시면 됩니다.

설치방법은 아래 링크를 참고하세요.
docker-compose 설치

docker compose를 설치하고 docker-compose.yml 파일을 작성 후 docker로 서비스를 구축합니다. 여기서는 wordpress 를 구축했습니다.

docker-wordpress-nginx/docker-compose.yml at master · 9to6/docker-wordpress-nginx · GitHub

깃허브 소스를 참고하시면 됩니다.

docker-compose.yml

version: "3.2"
services:
web:
build: .
ports:
- "80:80"
volumes:
- wordpress:/var/www/html
depends_on:
- php
php:
image: wordpress:4.8-php7.1-fpm-alpine
depends_on:
- db
restart: always
ports:
- "9000:9000"
volumes:
- wordpress:/var/www/html
db:
image: mariadb:10.2.6
volumes:
- db_data:/var/lib/mysql
restart: always
ports:
- "3306:3306"

docker compose의 파일을 보면 wordpress를 mariadb 와 함께 설치해서 wordpress web service 를 구성하게 됩니다.

이제 wordpress 설치를 시작하게 되고 첫 화면이 뜨고 난뒤, plugin 이나 theme 를 추가하기 위해 들어가보면 목록이 나오지 않습니다.
에러가 났다고 나오고, (wp-setting.php ?? 기억이 명확하지 않네요..)의 어떤 부분에서 에러가 났다고 합니다.
이제부터 문제 해결 과정입니다.

docker compose 문제 해결 과정

extra_hosts 추가

위의 에러난 부분을 찾아가서 php 소스를 수정, echo 로 확인해봤습니다.
wordpress 내부에서 https 를 이용 api.wordpress.org 에 request 를 보내는 부분에서 계속 에러가 납니다.

구글링을 해봤더니, wordpress docker 내부에서 api.wordpress.org 의 도메인을 lookup을 못해서 일 것이라는 글을 보고 host를 추가해봤는데,

php:
image: wordpress:4.8-php7.1-fpm-alpine
depends_on:
- db
restart: always
ports:
- "9000:9000"
volumes:
- wordpress:/var/www/html
extra_hosts:
- "api.wordpress.org:66.155.40.202"

같은 증상이었습니다…

iptables 추가

전혀 해결이 되지 않아서 또다른 방법을 찾던 중 나온 방법이 iptables를 수정하는 것이 었습니다.
현재 상황이 패킷이 나가지 않는 문제라고 판단했을 때, iptables 를 이용해서 해결 할 수 있을 것이라고 판단하고 적용해봤습니다.

docker 1.10, 1.11 do not infer MTU from eth0; docker 1.9 does · Issue #22028 · moby/moby · GitHub

좋아요도 두개나 받은 내용으로 적용을 해봤는데…

실행이 되었습니다.

이렇게 해결되었다는 기쁨(?)을 느끼고 이제 마무리를 지었는데…

또다른 문제. 다시 원점으로…

제가 모바일 어플의 서버로 사용하던 rails application을 또다른 docker 파일로 실행했는데, 메일이 나가지 않는 문제를 확인했습니다. 이 rails 앱은 smtp 를 사용해서 메일을 보내는 기능이 있었는데 메일이 나가지 않아서 ruby library 파일을 직접 수정하면서 디버깅을 시작했습니다.

문제는 smtp 를 보내는 부분에서 났기 때문에 네트워크 문제로 판단, 결국 다시 원점으로 돌아갔습니다. ㅠㅠ

이렇게 또다시 하루정도 iptables 룰 도 바꿔보고 구글링도 해보고 이것저것 해보게 되었습니다.

이때쯤 iwinv 서비스 이용을 포기할 생각을 잠시 하게 되었습니다…만, 심기일전 하고 다시 구글링.

결국 찾은 해결책과 원인

마침내 찾은 해결책.
containers in docker 1.11 does not get same MTU as host · Issue #22297 · moby/moby · GitHub

docker network 를 구성할 때 mtu 설정을 별도로 해줘야한다는 것이 었습니다.

이제 뭔가 이해되는 느낌…
docker compose 로 docker application을 실행하게 되면,
docker 엔진이 별도의 sub network 를 구성하게 되고, wordpress web app 과 mariadb는 sub network 안에서 통신을 하게 됩니다.
이 때 mtu 사이즈가 1450 이상이었기 때문에 문제가 발생했던 것입니다.

해결을 위해서는
1. 첫번째로, docker-compose 안에 이렇게 network 구성을 해주는 방법이나,

networks:
default:
driver: bridge
driver_opts:
com.docker.network.driver.mtu: 1450
  1. 두번째로는, 미리 생성된 network를 이용하는 방법입니다.
$ suod docker network create -o "com.docker.network.driver.mtu"="1450"

networks:
default:
external:
name:

이 해결책을 찾아보고 다시 두번째 해결책이었던 iptables의 명령어에 대해 찾아봤는데,

TCPMSS target

Under normal circumstances, this means the size of the MTU (Maximum Transfer Unit) value, minus 40 bytes.

정상적 상황에서 MTU 사이즈에서 40바이트를 빼주는 것이라고 하네요.
아마 이래서 잘 작동했었나 봅니다. SMTP 의 패킷은 40을 빼줘도 더 1450보다 더 패킷 사이즈가 컸나 봅니다.

하지만 보다 정확한 해결책은 MTU사이즈 수정입니다.

이제 다시 SMTP 로 메일을 보내봅니다. 정상적으로 동작합니다.

결론

  • iwinv 에 docker 를 사용은 비추
  •  그러나 이 글을 읽어봤다면 추천;;;
  • docker 를 사용하지 않으면 손쉽게 사용가능 하니 좋은 서비스 저렴하게 사용 가능
  • docker 사용을 하시겠다면 매뉴얼의 MTU 설정과 별도 docker network 의 MTU 설정도 유념해야 함

서버 이전 경험 공유기 – 2. Let’s Encrypt

서버 이전 경험 공유기 – 2. Let’s Encrypt

이번에 서버이전을 하면서 이것저것 알게된 지식 및 경험을 공유하고자 이 글을 작성합니다.

이전 글은 여기서 볼수 있습니다.

Let’s Encrypt

이 전 글에서 간단히 언급했지만, Let’s Encrypt 라는 https 보급 확산을 위한, 무료 인증서 발급 프로젝트 입니다.

사실 예전부터 개인 서버에 https 를 적용하고 싶었지만, 비용이 개인이 부담하기엔 적은 금액이 아니라서 도입을 망설이고 있었습니다.
이런 찰나에 이런 프로젝트가 있다는 사실을 알게 되어 제 서버에 도입을 하지 않을 수가 없었습니다.

설치

Let’s Encrypt 를 설치하기 위해서는 Certbot 이라는 클라이언트가 필요합니다.

Install Certbot

위의 사이트를 들어가면 certbot 을 설치하는 법이 자세히 나옵니다.

간단히 정리하면,

$ wget https://dl.eff.org/certbot-auto
$ chmod a+x ./certbot-auto
$ ./certbot-auto --help

wget 으로 다운로드 받은 뒤, 실행권한 주면 끝입니다. 간단합니다.

certbot-auto 는 현재(version 0.15.0) nginx 와 apache를 지원하고 있습니다. 만약 nginx 나 apache 를 직접(apt-get or yum) 설치했다면 plugin 을 이용해서 연동할 수 있을 것입니다.

–apache Use the Apache plugin for authentication & installation
–standalone Run a standalone webserver for authentication
–nginx Use the Nginx plugin for authentication & installation

하지만, 저는 docker 를 이용한 관계로 그렇게 하지 못하고 다른 방식으로 설치 진행했습니다.

GitHub – 9to6/docker-nginx: Docker for nginx

제 github 에 dockerfile 및 readme 를 참고 하시면 되겠습니다.

핵심은 certbot 설치 후,

$ ./certbot-auto certonly --standalone --email your@email.com -d example.com -d www.example.com

위 명령 실행입니다. example.com 대신 본인의 도메인을 입력하시면 됩니다.

처음으로 실행하셨다면, 본인 이메일 입력하는 란이 나오고,
이메일을 입력 한 뒤에는,
기꺼이 본인의 이메일을 EFF(Electronic Frontier Foundation) 에 제공하겠냐고 물어보는데 저는 그냥 제공해드렸습니다. ㅎㅎㅎㅎ

Let’s Encrypt 는 3개월 마다 한번씩 갱신해야합니다.

매번 신경 쓰기 힘드므로 crontab 에 등록해줍니다.

아래 내용은 매일 새벽 1시에 renew 를 시도하고, 성공시 nginx-simple 이라는 docker container 내부의 nginx의 설정을 다시 reload 하라는 뜻 입니다.

$ sudo echo "0 1 * * * /home/user/certbot-auto renew --quiet --renew-hook \"/usr/bin/docker exec nginx-simple nginx -s reload\"" | sudo tee -a /var/spool/cron/crontabs/root

결론

https 설치가 무사히 완료되었습니다.
이제 appstore application 의 adhoc 버전 배포할 때 굳이 dropbox를 써야하는 번거로움도 사라지겠네요. (다만 요즘 앱개발 할 일이 전혀 없습니다…)

https 적용으로 보안성도 강화되었습니다.
SSL Server Test (Powered by Qualys SSL Labs) 기념으로 이곳에서 보안성 테스트도 해줬습니다.
점수가 괜찮은 듯 합니다.

만족스럽습니다. 여러분들도 https 적용하시고 https 의 빠른 보급에 작은 기여를 해주셨으면 합니다.

서버 이전 경험 공유기 – 1. Dockerizing

이번에 서버이전을 하면서 이것저것 알게된 지식 및 경험을 공유하고자 이 글을 작성합니다.

서버 이전

서버 이전을 하게 되었습니다.
기존엔 cloudv 를 쓰고 있었는데, 같은 회사에서 나온 iwinv 가 한국형 AWS가 되겠다고 하고 과감하게 출사표를 던저서 가격을 보던 중, iwinv 가 압도적으로 좋다고 판단해서 서버이전을 마음먹었습니다.

기존 cloudv 사양

1core, 3G memory, 100G ssd -> 월 31900원

이전 iwinv 사양

2core, 6G memory, 25G ssd -> 월 20900원

iwinv 는 블록스토리지 20g 추가 당 2000원.

굳이 이전하지 않을 이유가 없었습니다.

아무튼…

이전하는 김에 제 개인 서버를 모두 Dockerizing 하기로 마음을 먹고, 작업을 진행하던 중에, 요즘 무료로 https 를 발급해주는 Let’s Encrypt 라는 프로젝트가 있다는 사실을 알게 되었습니다.

그래서 이것도한 시도를 하겠다는 마음을 덜컥 먹어버린…

이런 이유로 시작한 설치 경험을 공유합니다.

Docker

소개

Docker 는 요즘 모르는 사람이 별로 없을 것 같습니다만, 상세소개는 페이지 링크로 대체합니다.

Official Site Overview
nacyot의 프로그래밍 이야기 :: 도커(Docker) 튜토리얼 : 깐 김에 배포까지

간단히 Docker 에 대해 설명하자면 아래 아키택트 이미지로 쉽게 표현이 가능할 것이라고 생각합니다.

Docker Architecture vs Virtual machine

Docker 를 이해하기 위해선 가상 머신(Virtual machine)과의 비교는 필수라고 생각합니다.

한마디로 제게 Docker 를 표현하라고 한다면, Virtual machine 의 장점(isolation, distribution)을 취했으나, 훨씬 더 비용이 적게드는 시스템이 아닐까합니다.

Docker 를 적용하는 이유

이런 도커를 이용해서 제 블로그 및 서버를 구성하기로 마음먹은 겁니다.

이유는 여러가지가 있지만 가장 큰 이유는, 개인서버는 형편상 이사갈 일이 많습니다.
좀 더 저렴하고 좋은 서비스가 나오면 이사를 가야하기 때문이죠.
적고보니 회사든 개인이든 비용문제는 같은 거군요..

Docker를 적용한다면 앞으로 다른 더 좋은 호스팅 서비스가 나올 경우, 쉽게 갈아탈 수 있게 하기 위함입니다. 도커 이미지만 Download 받고 실행하면 그만이거든요.

Dockerizing 본격 시작

이 블로그는 블로그계의 원탑 wordpress 로 이뤄져있고, 워드프레스는 역시 유명한 만큼 자료가 많더군요.

Quickstart: Compose and WordPress

Docker 공식 사이트에 이렇게 docker compose 로 결합하는게 나옵니다.

하지만 부족합니다…
이유는 저는 일단 mysql 을 사용하지 싫고, mariadb를 사용하고 싶기 때문이며,
하나는 역시나 이것또한 비용 문제로 docker image size 를 조금이라도 줄이고 싶기 때문입니다.

그러기에 저는 Alpine Linux 를 쓸 생각을 하게 됩니다.

Using docker compose

GitHub – 9to6/docker-wordpress-nginx: Docker compose for WordPress

docker compose 를 이용해서 워드프래스를 구성하실 분은 위 링크를 참고하시면 좋을 듯합니다.

구성은,

nginx 1.13 alpine, mariadb 10.2.6, wordpress 4.8 alpine

으로 구성했으며, wordpress Plugin인 duplicator 의 손쉬운 사용을 위해, 기본 Dockerfile에서 zip 라이브러리를 추가했습니다.

Using only Dockerfile

심플하기는 위에 것보다 아래 링크가 더 심플합니다.
GitHub – 9to6/docker-wordpress: docker + nginx + mariadb + supervisor + php7

이건 docker compose 를 사용하지 않고, 하나의 도커파일에 nginx + mariadb + wordpress + supervisor 를 한번에 담은 것으로 단순 wordpress 를 호스팅하길 원하시는 분은 이것이 훨씬 단순할 것입니다.

$ sudo docker pull 9to5/wordpress

Docker hub 에 이미지도 올려놓았으니 필요한 분들은 사용하시면 됩니다.

결론

이렇게 해서 도커를 이용해서 워드프레스 서버 구성을 끝냈습니다.
여러분이 보고 있는 이 화면이 결과물입니다.

다음 글은 wordpress 블로그에 무료 https 적용하는 방법을 기술하겠습니다.

ubuntu 14.04(trusty)에 docker install

Ubuntu 우분투 14.04 docker 설치

$ sudo apt-get update
$ sudo apt-get install -y docker-engine

을 하면 에러가 나고 아래와 같은 메시지를 만나게 됩니다.

Reading package lists... Done
Building dependency tree
Reading state information... Done
docker-engine is already the newest version.
You might want to run 'apt-get -f install' to correct these:
The following packages have unmet dependencies:
docker-engine : Depends: libsystemd-journal0 (>= 201) but it is not going to be installed
Recommends: aufs-tools but it is not going to be installed
Recommends: cgroupfs-mount but it is not installable or
cgroup-lite but it is not going to be installed
Recommends: git but it is not going to be installed
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).

보면 docker가 libsystemd-journal0에 의존성이 걸려있어서 그런데요.
설치가 안되는 이유는 잘 모르겠으나, 그냥 수동으로 설치해줬습니다.

파일을 찾아보다가 나중에 또 이런일이 생길 듯하여 기록에 남겨둡니다.

$ wget http://kr.archive.ubuntu.com/ubuntu/pool/main/s/systemd/libsystemd-journal0_204-5ubuntu20_amd64.deb

위 명령으로 *.deb 파일을 다운로드 받은 뒤에 수동 설치합니다.

$ sudo dpkg -I libsystemd-journal0_204-5ubuntu20_amd64.deb

설치 후 다시 docker install 을 시도합니다.

$ sudo apt-get install -y docker-engine

정상 설치가 되었습니다.

Reading package lists... Done
Building dependency tree
Reading state information... Done
docker-engine is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 29 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up docker-engine (17.05.0~ce~rc3-0~ubuntu-trusty) ...
docker start/running, process 3434
Processing triggers for ureadahead (0.100.0-16) ...

설치가 잘 되었는지 확인합니다.

$ docker

정상 설치되었다면 usage가 나옵니다.

잘 설치되었다면 이제 docker를 잘 이용하시면 됩니다.

p80.pool.sks-keyservers.net: Host not found

AWS의 Opsworks에서 새로운 instances를 만들다가 만난 에러를 정리해둡니다.

AWS의 Opsworks 는 인스턴스를 새로 생성하면 등록되어있는 Chef Recipe 들을 자동으로 실행해주는 툴입니다.

이번에 Instance 한개를 추가로 생성하고, 그 Instance에 하나의 App 을 배포하려고 기존 Layer에서 추가로 Instance 를 생성하게 되었습니다.

그런데 갑자기 에러가 발생해서 로그를 봤더니 이런 로그가 있었습니다.

Mixlib::ShellOut::ShellCommandFailed
------------------------------------
execute[install-key 58118E89F3A912897C070ADBF76221572C52609D] (/var/lib/aws/opsworks/cache.stage2/cookbooks/apt/providers/repository.rb line 28) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '2'
---- Begin output of apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv 58118E89F3A912897C070ADBF76221572C52609D ----
STDOUT: Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --homedir /tmp/tmp.YjqEGDmda9 --no-auto-check-trustdb --trust-model always --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv 58118E89F3A912897C070ADBF76221572C52609D
?: p80.pool.sks-keyservers.net: Host not found
gpgkeys: HTTP fetch error 7: couldn't connect: Success
STDERR: gpg: requesting key 2C52609D from hkp server p80.pool.sks-keyservers.net
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
---- End output of apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv 58118E89F3A912897C070ADBF76221572C52609D ----
Ran apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv 58118E89F3A912897C070ADBF76221572C52609D returned 2

Resource Declaration:
---------------------
# In /var/lib/aws/opsworks/cache.stage2/cookbooks/ops-docker/recipes/install.rb

4: apt_repository 'docker' do
5: uri node['docker']['package']['repo_url']
6: distribution node['docker']['package']['distribution']
7: components ['main']
8: keyserver node['docker']['package']['repo_keyserver']
9: key node['docker']['package']['repo_key']
10: end
11:

Compiled Resource:
------------------
# Declared in /var/lib/aws/opsworks/cache.stage2/cookbooks/ops-docker/recipes/install.rb:4:in `from_file'

apt_repository("docker") do
action :add
retries 0
retry_delay 2
cookbook_name "ops-docker"
recipe_name "install"
uri "https://apt.dockerproject.org/repo"
distribution "ubuntu-trusty"
components ["main"]
keyserver "hkp://p80.pool.sks-keyservers.net:80"
key "58118E89F3A912897C070ADBF76221572C52609D"
cache_rebuild true
end

[2017-05-03T09:17:52+00:00] INFO: Running queued delayed notifications before re-raising exception
[2017-05-03T09:17:52+00:00] ERROR: Running exception handlers
[2017-05-03T09:17:52+00:00] ERROR: Exception handlers complete
[2017-05-03T09:17:52+00:00] FATAL: Stacktrace dumped to /var/lib/aws/opsworks/cache.stage2/chef-stacktrace.out
[2017-05-03T09:17:52+00:00] ERROR: apt_repository[docker] (ops-docker::install line 4) had an error: Mixlib::ShellOut::ShellCommandFailed: execute[install-key 58118E89F3A912897C070ADBF76221572C52609D] (/var/lib/aws/opsworks/cache.stage2/cookbooks/apt/providers/repository.rb line 28) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '2'
---- Begin output of apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv 58118E89F3A912897C070ADBF76221572C52609D ----
STDOUT: Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --homedir /tmp/tmp.YjqEGDmda9 --no-auto-check-trustdb --trust-model always --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv 58118E89F3A912897C070ADBF76221572C52609D
?: p80.pool.sks-keyservers.net: Host not found
gpgkeys: HTTP fetch error 7: couldn't connect: Success
STDERR: gpg: requesting key 2C52609D from hkp server p80.pool.sks-keyservers.net
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
---- End output of apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv 58118E89F3A912897C070ADBF76221572C52609D ----
Ran apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv 58118E89F3A912897C070ADBF76221572C52609D returned 2
[2017-05-03T09:17:53+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

해서 검색을 시작했습니다.
저는 OpsWorks나 Docker에 서툴러서 뭔 실수를 했나 싶었는데 결과는…
그냥 단순히 서버 다운… OTL.

p80.pool.sks-keyservers.net: Host not found
gpgkeys: HTTP fetch error 7: couldn’t connect: Success

그냥 저 서버가 죽은거 였네요.

저 서버가 Docker설치시 기본으로 바로보는 PGP key server인 듯..
아래 링크가 이 에러와 관련된 Thread입니다.

Key server down for get.docker.com · Issue #13555 · moby/moby · GitHub

여기 가보면 kris라는 사람이
기존 Docker가 사용하는 서버주소를
From,

p80.pool.sks-keyservers.net

To,

hkp://keyserver.ubuntu.com:80

로 변경해주라고 답을 달아놨더군요.

 

결론

아무튼 이 버그의 결론은,
잠시뒤에 다시 시도 해본다;;;;

서버가 살아날 시간을 주는 것입니다;;