멜번에서 어플리케이션 아키텍트 및 개발자로 일하고있는 노동자입니다.

도커사용에 처음 작업할때 사용되어지는 커맨드들을 Tomcat 이미지 기준으로 정리해 봅니다.

Docker 서비스 시작

$> service docker start

$> chkconfig docker on  // --> start on boot

Tomcat Docker이미지 받기

$> docker pull tomcat:latest

설치된 Docker이미지 확인

$> docker images

설치된 이미지 삭제

$> docker rmi tomcat:latest

컨테이너 생성

$> docker run -it  -p 8888:8080 --name tomcat8888 tomcat:latest /bin/bash

$> docker run -it  -p 8889:8080 --name tomcat8889 tomcat:latest /bin/bash

컨테이너 생성시 Host컴퓨터와 컨테이너간에 데이터를 공유하고자 하는경우 -v Option을 추가한다.

다음은 컨테이너의 /usr/local/tomcat/logs 디렉토리를 호스트의 /root/dockerfiles/tomcat/logs로 연결한다.

$> docker run -it  -p 8888:8080 -v /root/dockerfiles/tomcat/logs:/usr/local/tomcat/logs --name tomcat8888 tomcat:latest /bin/bash

한개이상 디렉토리를 공유하고자하는 경우.

$> docker run -it  -p 8888:8080 \n

    -v /root/dockerfiles/tomcat/logs:/usr/local/tomcat/logs \n

    -v /root/dockerfiles/tomcat/webapps:/usr/local/tomcat/webapps \n

    --name tomcat8888 tomcat:latest /bin/bash

** -v 옵션을 통해 공유하는 디렉토리는 컨테이너 쪽의 디렉리는 초기화 되면서 안에있는 내용이 모두 삭제된다.

생성된 Docker 컨테이너 확인

$> docker ps

$> docker ps -a

컨테이너 삭제

$> docker rm tomcat8889

다음부터는 start 명령으로 Docker를 실행 및 중지

$> docker start tomcat8888

$> docker stop tomcat8888

Docker컨테이너 안으로 들어가기

$> docker attach tomcat8888

외부 명령으로 컨테이너안의 명령수행

$> docker exec tomcat8888 /usr/local/tomcat/bin/startup.sh

컨테이너끼리 통신을 위해서 네트워크 생성하기

$> docker network create network1

$> docker network ls

동일한 네트웍에서 컨테이너 생성하기

다음은 두개의 Tomcat Server는 Mysql컨테이너와 동일한 네트웍에 존재하기 때문에 서로 통신이 가능해진다.

$> docker run -it  -p 8888:8080 --name tomcat8888 --network network1 tomcat:latest /bin/bash

$> docker run -it  -p 8889:8080 --name tomcat8889 --network network1 tomcat:latest /bin/bash

$> docker run -it  -p 3306:3306 --name steven-mysql --network network1 -e MYSQL_ROOT_PASSWORD=1234 -d mysql:latest

위에서 생성한 MySql에 접속해봅니다. 192.168.56.107은 호스트 서버의 IP다. (컨테이너 생성시 3306 --> 3306 했기때문에 가능)

[root@docker ~]# mysql -h 192.168.56.107 -u root -p

Enter password:

Welcome to the MariaDB monitor.  Commands end with ; or \g.

Your MySQL connection id is 3

Server version: 5.7.19 MySQL Community Server (GPL)

Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MySQL [(none)]>

컨테이너 에서 컨테이너 정지없이 빠져나오기

$> Ctrl+p, Ctrl+q

클라우딩 컴퓨팅환경과 함께 조명받고있는 분야가 서버관리 기술중에 하나인 프로비저닝분야인것 같습니다. 그에따라서 많은 서버관리를 자동화 하고 서버관리 또한 코드화하여 자동화 하는 기술인것 같습니다.

최근에 Chef쪽에 기웃기리다 최근에 다시 Puppet쪽으로 리서치하고있습니다. 파죽지세로 올라오는 AWS는 Puppet보다는 Chef쪽에 있는것 같아 Chef에 기대볼까 했었는데, 실제로 Job market에서는 Chef보다는 Puppet이 좀 값을 처주는 같고 실제 멜번의 경우 DevOps커뮤니티에서Puppet에대한 수요가 많다는 느낌입니다.

간단히 Puppet 서버와 Agent설치하는 과정을 정리해보았습니다.

기본적으로 설치는 인터넷에 많이 공개된 가이드를 따라하면 되겠으나 다른 일반 패키지와 특이한점은(?) 서버와 에이전트간에 통신을 위해 처음에SSL인증 절차가 필요하기 때문에 이부분을 좀 미리 이해하면 더 쉬울것 같습니다.

Prerequisites

1.     Server              : CentOS Linux release 7.3.1611 (Core)     : puppet.example.com (IP:192.168.56.102)

2.     Agent1             : CentOS Linux release 7.3.1611 (Core)     : cent1.example.com

3.     Agent2             : CentOS Linux release 7.3.1611 (Core)     : cnet2.example.com

편의상 모든 서버는 CentOS를 사용했습니다.

편의상 모든 테스트를 위해서 관리대상이 되는 Node 두개를 마련했습니다.

설치 진행은 VirtualBox guest OS에서 진행했습니다.

서버 Hostname 설정 및 Agent 서버에 Master 서버 등록

Puppet Master server

Hostname 을 설정 합니다.

/etc/sysconfig/network, /etc/hosts 파일을 편집하고 hostname 커맨드를 이용하여 설정할수도 있지만 CentOS 7 에서는hostnamectl를 이용하여 간단히 변경할 수 있습니다.

$> hostnamectl status : 현재 설정확인

$> hostnamectl set-hostname puppet.example.com                 : 새 Hostname 설정 

Puppet Agent(cent1, cent2)

Hostname 을 설정 합니다.

$> hostnamectl set-hostname cent1.example.co                      : For Agent1

$> hostnamectl set-hostname cent2.example.co                      : For Agent2

참조 : 

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec_Configuring_Host_Names_Using_hostnamectl.html

서버 Hostname 설정 및 Agent 서버에 Master 서버 등록

Puppet서버는 클라이언트와 8140포트를 통해서 통신하기 때문에 해당포트가 열려있어야 합니다. CentOS는 firewall-cmd 명령을 이용하여(없으면 설치하셔야할것 같습니다.) 간단히 설정할 수 있습니다.

$> firewall-cmd –add-port=8140/tcp

$> firewall-cmd –add-port=8140/tcp --permanent      : 영구적으로 반영합니다.

그리고 Agent서버의  “/etc/hosts”파일을 열어서 마스터 서버를 등록해줍니다.

192.168.56.102 puppet puppet.example.com 

이젠 Server와 Agent를 설치할 준비가 되었습니다.

Enable the official Puppet Labs collection repository

대부분 서버에는 기본적으로 Puppet을 설치하기위한 리포지토리가 없기때문에 서버와 클라이트쪽 모두에게 Puppet Lab 리파지토리 컬렉션을 등록해줘야 합니다.

$> rpm -ivh https://yum.puppetlabs.com/puppetlabs-release-pc1-el-7.noarch.rpm

위 명령을 실행하고 나면, /etc/yum.repos.d/에 puppetlabs-xx.repo 가 등록되어 있는 것을 확인 할 수 있을 것입니다.

참고로 패키지 관리자별 리포지토리 파일을 다음의 URL에서 확인 할 수 있으며 선택적으로 등록할 수 있습니다.

§  http://yum.puppetlabs.com

§  http://apt.puppetlabs.com/

Puppet 서버 설치/실행

다음 커맨드로 설치하면 기본 설치는 끝납니다.

$> yum -y install puppetserver

Puppet서버는 기본적으로 JVM으로 구동됩니다. 그래서 실제로 프로세스를 확인해보면 서버는 서버에 설치된 java를 이용하여 서버를 구동하면서 여러가지 설치된 jar 파일이 –cp에 걸려있는 것을 확인할수있습니다.

설치후 기본적으로 JVM 메모리옵션 puppet환경 설정 중에 JVM 옵션으로 -Xms3g –Xmx3g로 잡혀있는데요 이것은 관리되어지는 Node에따라 조정되어야하는데 현재 로컬에서 테스트 하므로 저의 경우-Xms500m -Xmx500m로 조정하는것이 좋을것 같습니다.

$> vi /etc/sysconfig/puppetserver

이제 서버를 실행합니다.

$> systemctl start puppetserver

$> systemctl enable puppetserver                    : 서버가 시작되면 자동 시작되도록

$> systemctl stop puppetserver                        : 서버 중지

Puppet Agent서버 설치/실행

다음 커맨드로 에이전트를 설치합니다.

$> yum -y install puppet-agent

다음 커맨드로 에이전트를 실행합니다.

$> /opt/puppetlabs/bin/puppet resource service puppet ensure=running enable=true

에이전트를 처음 실행하면 에이전트는 서버에서 SSL인증 요청을 하게됩니다.

그러면 서버에서 해당 요청에 대해서 Sign을 해주면 그때부터 Agent는 Puppet의 관리대상이 되는 Node 가 되어집니다.

위의 명령이 처음 실행된 상태라면 서버에서 요청된 내용을 다음과 같이 확인 할수 있습니다.

$> puppet cert list

그러면 대기준인 목록이 나타납니다.

"cent1.example.com" (SHA256) EB:62:~~~

"cent2.example.com" (SHA256) ED:33:~~~

그리고 Sign요청된 클라이언트들의 요청은 “/etc/puppetlabs/puppet/ssl/ca/requests” 에 파일로 생성됩니다.

다음의 명령으로 인증 요청에 대해서 Sign해 줍니다.

$> puppet cert sign “cent1.example.com”

$> puppet cert sign “cent2.example.com”

또는 다음의 명령으로 일괄적으로 Sign해 줄수도 있습니다.

$> puppet cert sign --all

이렇게 인증이 완료되면

“/etc/puppetlabs/puppet/ssl/ca/requests” 에 요청된 파일들은 삭제되고

“/etc/puppetlabs/puppet/ssl/ca/signed”이 인증이 완료된 파일들로 이관됩니다.

다음의 명령으로 인증이 완료된 클라이언트 목록을 확인 할 수있습니다.

$> puppet cert list --all

이렇게 하므로써 Puppet 서버와 Agent의 기본설치는 마무리 됩니다.

Puppet Server/Agent테스트

“/etc/puppetlabs/code/environments/production/manifests”에 site.pp라는 파일로 다음의 내용을 작성합니다.

file {'/tmp/example-ip':                    # resource type file and filename

  ensure  => present,                       # make sure it exists

  mode    => '0644',                                # file permissions

  content => "My Public IP Address: ${ipaddress_eth0}.\n", 

}

그리고 30분(기본값)을 기다리거나 에이전에에서 다음의 커맨드를 실행시켜서

$> puppet agent --test

/tmp/example-ip 파일의 내용과 생성된 권한을 확인해 봅니다.

*** 위에서 작성된 site.pp파일에서 ipaddress_eh0변수는 팩터(Facter) 가 수집해온 정보 변수중 하나입니다.

Puppet 서버에서 다음의 명령을 실행시켜 보면 팩터가 관리대상이 되는 노드들로 부터 어떤 정보들을 수집해왔는지 확인 할 수 있습니다.

$> facter

참고 : https://www.digitalocean.com/community/tutorials/how-to-install-puppet-4-in-a-master-agent-setup-on-centos-7

https://www.digitalocean.com/community/tutorials/how-to-install-puppet-4-on-ubuntu-16-04

라우팅 데이블을 설정할때마도 좀 혼동이 되어 정리해봅니다.

The route table is the place to define where packets originating within a given subnet should go.  The "Destination" is the pattern for where the packet is trying to end up (think final destination), and the "Target" is where the packet should go next, to get it one step closer to the intended destination.  

여기서 혼동되는 이유가 "Destination"이라는 것 때문인것 같은데, 다시생각하고 다시생가하면 "Destination"이 맞는데..... 헷갈릴때는 왜 "Source"라고 하지 않았을까 생각도 하게됩니다.

가령, 다음과 같은 라우팅 테이블을 있을경우 

(다음은 VPC 10.213.0.0./16 영역내에있는 한개의 Private Subnet 을 보여줍니다)

다음과 같이 라우트 테이블을 읽으면 이해가 쉬울것 같습니다.

Route 테이블의 정보는 "XXX(Destination) 로 가려고하는 패킷들은, OOO(Target)으로 보내라"라고 읽으면 된다.

1.  10.213.0.0/16 으로 데이터를 보내려고하는(destination : 목적지) 패킷들은 모두 내부(local)로 브로드캐스팅 하라.

     10.213.0.0/16 은 VPC내의 IP들을 의미하므로 VPC내부에있는것으로 읽으면 됩니다.

2.  (그밖의) 모든 곳으로 데이터를 보내려고하는(destination : 목적지) 패킷들은 모두 NAT( eni-e4b5cc80/i-70b5beac)로 브로드캐스팅 하라.

3.  10.200.0.0/24(다른 VPC의 subnet) 으로 데이터를 보내려고하는(destination : 목적지) 패킷들은 모두 VPC Peering 으로 브로드캐스팅 하라.

스토리지나 데이터베이스를 백업 및 복구하는 과정에서 설정하게되는 중요 지표(값)이 몇개 등장하는데요 RPO(Recovery Point Object) 와  RTO(Recovery Time Objective) 에 대해서 정리해 봅니다.

이 두가지 지표는 결국 Recovery와 아주 밀접한 과계가 있습니다. 

1. RTO(Recovery Time Objective)

어떠한 특별한 어플리케이션 없이도 얼마나 버틸수 있느냐와 관계가 있습니다(시간). 그래서 종종 허용할 수 있는 최대 허용 다운타임과 연관되어 사용되기도 합니다.

RTO는 실제로 리플리케이션, 테이프/디스크 백업에 사용됩니다. 또한 HA 클러스터 구성이나 혹은 그 이상의 견고한 시스템을 구축하는 것과 동반하여 사용되기도 합니다.

만일 RTO가 0(zero)이라고 한다면 이는 해당 애플리케이션이 완벽하게 이중화되어 있고 데이터가 오프 사이트와 그 밖의 장소에 복제되어 보관되어 있어야 함을 의미합니다. 만일 RTO가 48시간 또는 72시간이라면 테이프 백업으로도 충분할 것입니다.

Maximum length of time a system can be down

Glacier takes 3 to 5 hours to restore objects

2. RPO(Recovery Point Object)

허용할 수 있는 데이터의 손실양과 관계되는 것으로 내가 손실을 경험/허용 할 수 있는 최대의 데이터 양이 얼마인가에 관한 문제입니다.. 

다른 말로 하면, 만일 내가 오후 7시에 백업을 하였고, 이 시스템이 다음날 4시(오전)에 붕괴되었다고 한다면, 내가 백업을 하고 난 이후의 데이터들은 완전히 날아가게 되는 것입니다. 이러한 상황에서 RPO는 바로 전날 백업한 것이 됩니다.

High backup frequency means low RPO

Write/delete event to trigger incremental backup means low RPO

결국, RTO와 RPO는 실제로 리던던시의 종류와 백업 인프라에 영향을 미치고 서로 연관이 있게 된다. RTO가 타이트해 질 수록 RPO도 타이트 해 진다. 물론 비용도 동반 상승하게 되고 인프라 환경에 더 많은 돈이 투자되어야 함을 의미하는 것이다.