::: STEVEN J.S MIN's Story :::

네트웍 설정 On VirtualBox

Steven J.S Min — Sat, 21 Mar 2020 09:51:13 +0900

아래의 글은 TechNote.kr@https://technote.kr/213 에서 정리된 글을 가저온것 입니다. 감사합니다.

가상 네트워크를 설정하기 위해서는 다음의 것들을 정해야 한다.

-. 어떤 하드웨어를 통해 가상화할 것인가.

: PC에 설치된 Ethernet 카드 중 어떤 카드를 통해 가상화하여 네트워크를 사용할 것인지 정한다.

-. 어떤 가상화 모드로 설정할 것인가.

: 설정가능한 6개의 가상화 모드 중 어떤 것을 사용할 것인지 정한다. 기본으로는 NAT가 설정되어 있다.

(참고로 VirtualBox의 네트워크라는 표현을 사용하기는 하였지만 정확히 말하면 virtualbox manual에서 볼 수 있듯이 virtual networking, 즉 virtualbox의 가상 네트워킹이다.)

연결되지 않음
NAT
NAT 네트워크
브리지 어댑터
내부 네트워크
호스트 전용 어댑터
일반 드라이버

NAT (Network Address Translation)

가상머신 내부 네트워크 -> Host PC 외부 네트워크 단방향 통신 가능
Host PC 내의 가상 머신 간의 통신 불가능

해당 모드는 기본 선택사항으로 가상 머신 내에서 단순히 인터넷 사용이나 파일 다운로드와 같은 용도로만 사용할 경우 설정이 가능하다. 가상 머신 내에서는 자체 사설 IP 주소를 사용하지만 실제 외부로 나갈 때는 Host PC가 가진 IP 주소를 바꿔 달고 나가게 된다. Host PC의 외부 네트워크에서는 내부의 가상 머신에 접근 불가능하다. (일반적으로 통용되는 NAT의 개념을 적용한 부분이라 자세한 설명은 넘어간다.)

즉, 아래 그림과 같이 NAT 모드일 경우 192.168.0.1의 주소를 사용하는 가상 머신은 외부 네트워크와 통신할 때 123.123.123.x 주소를 달고 외부와 통신하게 된다. 반면 192.168.0.x 의 주소를 가진 다른 가상 머신들과는 통신이 불가능하다.

NAT Network

가상머신 내부 네트워크 -> Host PC 외부 네트워크 단방향 통신 가능
Host PC 내의 가상 머신 간의 통신 가능

해당 모드는 NAT와 거의 동일하지만 Host PC 내의 가상 머신끼리 통신이 가능하다는 점이 다르다. 가상 머신 간에 상호 통신이 필요한 작업이 있다면 해당 모드를 사용해야 한다.

NAT Network의 경우는 아래 그림과 같이 NAT 와 다 동일하지만 192.168.0.x 의 주소를 가진 다른 가상 머신들과도 통신이 가능하다는 점이 다르다.

브리지 어댑터 (Bridged Adapter)

Host PC와 동등한 수준의 네트워크 구성
추가의 IP 할당이 필요함

해당 모드는 가상 머신의 네트워크를 Host PC 와 동등 수준으로 구성할 수 있게 해준다. 즉, 예를 들어 Host PC의 네트워크가 192.168.0.2로 설정이 되어 있다면 가상 머신의 네트워크 또한 192.168.0.4 정도로 같은 네트워크로 설정할 수 있는 것이다. 근데 잘 생각해 보면 실제 물리적인 네트워크 인터페이스는 Host PC의 Ethernet 카드 하나밖에 없다. 그렇다면 어떻게 Host PC와 가상 머신의 네트워크를 구분해 내는 것일까. VirtualBox 의 Manual에 따르면 소위 "net filter"라 불리는 Host PC의 network device driver를 사용하여 구분해 낸다고 한다. 해당 net filter를 통해 가상 머신은 자신의 data를 Host PC의 네트워크 카드로 부터 분리해내고 삽입하기도 한다.

브리지 어댑터의 경우 아래 그림과 같이 물리적으로는 Host PC 내에 존재하지만 Host PC의 주소와 동등한 수준의 별도의 주소를 가지고 외부와 통신한다.

내부 네트워크 (Internal Network)

Host PC와 독립적인 내부 네트워크
같은 Host PC 내의 가상 머신 간 연결이 가능

해당 모드는 브리지 어댑터와 많은 부분에서 유사하지만 가장 큰 차이점으로 외부와 통신이 되지 않는다는 점이 있다. 즉, Host PC의 네트워크와 분리되어 있고, Host PC 내 가상 머신 간에만 상호 연결하여 통신이 가능하다. Host PC의 물리적인 네트워크 인터페이스와 연결되어 있지 않다.

아래 그림과 같이 내부 네트워크는 Host PC 네트워크와 분리되어 있고, 가상 머신 간에만 통신이 가능하다.

호스트 전용 어댑터 (Host-only Adapter)

Host PC를 포함한 내부 네트워크 (외부 네트워크와는 단절)
같은 Host PC 내의 가상 머신 간 연결이 가능

해당 모드는 "브리지 어댑터"모드와 같이 Host PC와 내부 가상 머신들과 통신이 가능하고, "내부 네트워크"모드와 같이 외부 네트워크와는 통신이 불가능하다. Host PC의 물리 네트워크 어댑터외에 별도의 Loopback 어댑터를 생성하여 해당 어댑터를 통해 통신한다.

호스트 전용 어댑터의 경우는 아래 그림과 같이 외부 네트워크가 단절되어 있다.

일반 드라이버 (Generic Driver)

거의 사용되지 않는 모드
UDP Tunnel networking과 VDE(Virtual Distributed Ethernet) 지원

CentOS 8 설정 on VirtualBox

Steven J.S Min — Fri, 20 Mar 2020 19:06:56 +0900

초기 CentOS8을 VirtualBox에 설치후, 기본적으로 필요한 설정 내용을 정리함.

Guest Editions 설치에 필요한 패키지 설치

>> sudo dnf install -y elfutils-libelf-devel

>> Devices > Insert Guest Additions CD Image… —> 필요에따라서 VBoxGuestAddtion.iso 파일을 다운받아 마운트

:: 위 작업을 위해서는 처음 Linux 설치시 devel-tool을 추가 선택해서 설치해줘야한다.

VirtualBox Network 설정

>> Bridged Adapter 설정 : 해당 모드는 가상 머신의 네트워크를 Host PC 와 동등 수준으로 구성할 수 있게 해준다

:: 예를 들어 Host PC의 네트워크가 192.168.0.2로 설정이 되어 있다면 가상 머신의 네트워크 또한 192.168.0.4 정도로 설정됨.

SSH 접속 허용 가능하도록 설정

>> firewall-cmd --permanent --zone=public --add-port=22/tcp

/etc/profile.d/에 커스텀 Shell파일 생성 --> PS1 프롬프트 변경/기본 Global Var설정

export export PS1='\h \[\e[32m\u\] \[\e[36m\W\] \[\e[33m\]\[\e[1m\]$ \[\e[0m\]'

export JAVA_HOME="/app/java/jdk"

export JRE_HOME="/app/java/jdk/jre"

export PATH=$PATH:/app/oc:$JAVA_HOME/bin

alias vi=vim

** 위의 내용은 나 개인의 어플리케이션에 종속된 설정입니다.

EPEL 리포지토리 설치

Configuration 패키지 설치

>> dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm

패키지가 잘 설치되었는지 확인

>> rpm -ql epel-release

EPEL Repository가 Enable되었는지 확인

>> dnf repolist -v

EPEL Repository에 포함된 패키지 체크

>> dnf repository-packages epel list

Hostname 변경

>> hostnamectl set-hostname workstation

>> /etc/hosts 에 Host Alias이름 추가

Host와 Guest간 공유폴더 설정

- Virtualbox에서 지정된 Guest서버에서 “설정 —> 공유폴더”에서 공유폴더 설정 ==> SharedFolder

- 게스트확장 설치 —> 위에서 “sudo dnf install -y elfutils-libelf-devel”를 통해서 이미 마운트 되어 있을수 있다.

- 게스트에서 다음 명령 실행

>> mount /dev/cdrom /media (readonly 에러는 무시)

- 게스트 에디션 설치

>> yum update kernel*

>> yum install gcc kernel-devel kernel-headers dkms make bzip2 perl

>> /media/VBoxLinuxAdditions.run

/media 폴더에서 나온 후 umount /media

>> mount -t vboxsf SharedFolder /SharedFolder

- 재부팅 시 자동 적용 되도록 명령어 추가

>> vi /etc/fstab (파일 열어서 수정)

>> 맨 아래 다음행 추가 “SharedFolder /SharedFolder vboxsf nodev,noexec,nosuid 0 0”

접속하려는 서버에 SSH Public 키 복사

>> ssh-copy-id -i ~/.ssh/id_rsa.pub mins1@192.168.0.218 —> 또는 steven.pub

>> ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.0.218 —> 또는 steven.pub

.ssh/config 파일 생성

# STEVEN Virtual Box ==============================================
Host workstation
    HostName 192.168.0.50
    User root
    Port 22
    IdentityFile ~/.ssh/id_rsa

Host server1
    HostName 192.168.0.83
    User root
    Port 22
    IdentityFile ~/.ssh/id_rsa

Host server2
    HostName 192.168.0.20
    User root
    Port 22
    IdentityFile ~/.ssh/id_rsa


Host centos8
    HostName 192.168.0.218
    User root
    Port 22
    IdentityFile ~/.ssh/id_rsa

# COMMON ==========================================================
Host git-codecommit.*.amazonaws.com
    User {AWS IAM KEY}
    IdentityFile ~/.ssh/id_rsa

Host github.com
    HostName github.com
    IdentityFile ~/.ssh/id_rsa
    User stevenjsmin

Host gitlab.com
    HostName gitlab.com
    IdentityFile ~/.ssh/id_rsa
    User stevenjsmin

파이선2/3 설치 그리고 기본 Python 설정

>> sudo dnf install python3

>> sudo dnf install python2

>> sudo alternatives --set python /usr/bin/python3

Ansible 설치 그리고 Python 설정

>> sudo dnf install ansible

그리고 명시적으로 Ansible이 Python3를 사용하도록 하기위해서는 ansible.cfg 파일에 다음 항목 설정

ansible_python_interpreter=/usr/bin/python3

참조 :: https://docs.ansible.com/ansible/latest/reference_appendices/python_3_support.html

일반사용자 Sudo User만들기

>> usermod -aG wheel username

일반사용자(Ansible remote_user)를 Sudo사용시 비빌번호 없이 수행하도록 Escalation 설정

>> usermod -aG wheel username

>> 아래의 두가지 방법 중 하나 선택

1. /etc/sudoers파일에서

%wheel ALL=(ALL) NOPASSWD: ALL

와 같이 설정해서 모든 wheel 그룹의 사용자가 비밀번호 없이 sudo 사용하도록 설정

또는

적절한 지시문이있는 파일을 /etc/sudoers.d/파일에 아래와 같이 생성

## password-less sudo for Ansible user

username ALL=(ALL) NOPASSWD: ALL

VirtualBox 포트 Forwarding 설정

>> firewall-cmd --zone=public --add-port=9999/tcp --permanent

>> firewall-cmd --zone=public --add-service=http --permanent

>> firewall-cmd --reload

그리고 VirtualBox의 Gust OS Networ설정에서 포트를 80 --> 9999로 설정하면 "http://127.0.0.1:80"으로 요청하면 Guest의 9999포트로 연결된다.

*** Guest IP로 연결하면 안된다.

추가 Applicaiton 및 소프트웨어 구성

/app 에 모두 설치

centos8 root /app $ ll

total 0

lrwxrwxrwx. 1 root root 20 Nov 26 16:06 apache-tomcat -> apache-tomcat-9.0.22

drwxr-xr-x. 9 root root 235 Nov 27 09:41 apache-tomcat-9.0.22

drwxr-xr-x. 3 root root 37 Nov 27 09:15 java

drwxr-xr-x. 7 root root 147 Mar 21 15:48 jenkins_2.176.2

drwxr-xr-x. 2 root root 63 Nov 14 16:46 oc

GIT 클라이언트 설치 및 설정

>> dnf install git

>> git config --global user.name "Steven Min"

>> git config --global user.email "steven.jsmin@gmail.com"

>> git config --list

** Git서버에 Public key 등록 "Settings --> SSH and GPG Keys --> New SSH Key"

VM Start with "Headless" mode as default

>> VBoxManage modifyvm "<<VM Name>>" --defaultfrontend headless

ssh 서버 접속을 위한 키생성 및 설정 과정

Steven J.S Min — Mon, 10 Jun 2019 20:40:59 +0900

1. 자신의 PC에 공개키와 비밀키 쌍을 생성

$ ssh-keygen

2. [k-name]과 [k-name].pub 이라는 키 쌍이 생성된다

steven
steven.pub

3. 이 공개키(steven.pub)를 서버에 등록하여야 한다.

$ scp steven.pub jenkins@52.78.151.36:/tmp/

또는 아래 설명된 ssh-copy-id 명령 사용

4. 이 공개키를 인증할 때 사용하기 위해 키의 내용을 ~/.ssh/authorized_keys 라는 파일에 추가하여야 한다.

$ ssh jenkins@52.78.151.36

$ cat /tmp/steven.pub >> ~/.ssh/authorized_keys

5. .ssh 디렉토리 내의 모든 파일을 읽고 쓸 수 없도록 권한을 설정 (600)

6. 하나의 키에 대해서 특정 명령어만 실행할 수 있게 설정도 가능

~/.ssh/authorized_keys 파일을 연 후
아래와 같이 해당 공개키 앞에 특정 명령어열을 추가해주면 된다.
command="scp -f /var/log/access.log" ssh-rsa AAA...

설정하면 해당 비밀키로는 /var/log/access.log 파일을 scp 명령어로 복사해오는 것 밖에 하지 못하게 된다.

---------------------

SSH key 동작방식

SSH 서버는 여러가지 방법으로 클라이언트를 인증할 수 있다. 그 중 가장 기본적인 방법은 패스워드를 사용하는 것으로 사용하기 쉽지만 가장 안전한 인증방법은 아니다.
비록 패스워드는 암호화되어 서버로 보내지지만 꾸준하고 반복적인 해커의 공격에 안전할만큼 복잡하거나 길지 않은 경우가 거의 대부분이다. 컴퓨팅 파워가 비약적으로 발전했기 때문에 자동화 된 스크립트를 사용한 brute-force 공격에 취약할 수 밖에 없다. 다른 추가적인 보안박식들도 있지만 SSH key가 가장 안정적이고 안전한 검증된 인증방식이다.

SSH 키 페어는 두개의 암호키로 SSH 서버가 클라이언트를 인증하는데 사용될 수 있다. 각 키 페어는 public 키와 private 키로 이루어진다.

Private 키는 클라이언트가 가지고 있고, 이 키는 절대적인 비밀(누구에게도 복사해 주거나 공개하면 안됨)로 해야만 한다. 어떤 식으로건 private 키가 알려지는 순간 공격자는 그 쌍이 되는 public 키로 설정된 서버에 아무 추가적인 인증 없이 로그인이 가능해진다. 추가적인 예방조치로 private 키를 passphrase로 암호화 해서 디스크에 저장할 수 있다.

쌍이 되는 public 키는 아무 걱정 없이 자유롭게 누구에게든 공유할 수 있다. Public 키로 메시지를 암호화 할 수 있는데, 그 암호화 된 메시지는 그 쌍이 되는 private 키로만 해석할 수 있다. (암호화에 사용한 public 키로도 암호화 된 메시지를 해석할 수 없다) 이런 특성이 키 페어를 사용한 인증방식에 사용된다.

Public 키는 SSH로 로그인하길 원하는 원격 서버에 업로드된다. 이 키는 사용자 어카운트의 ~/.ssh/authorized_keys 라는 특별한 파일에 추가된다.

클라이언트가 SSH key를 사용해 인증하려고 시도하면, 서버는 클라이언트가 private 키를 가지고 있는지 여부를 테스트 할 수 있다. 클라이언트가 private 키를 가지고 있는걸 증명하면 쉘 세션이 생성되거나 요구된 명령을 실행한다.
이 전체적인 흐름은 다음과 같다.

1. 클라이언트가 서버에 SSH 연결을 요청한다.
2. 서버는 랜덤 챌린지(랜덤 데이터 스트링)를 생성해 클라이언트에게 보낸다.
3. 클라이언트는 서버로 부터 받은 챌린지(C)를 자신이 가지고 있는 private 키로 암호화해서 암호화 된 메시지를 서버로 보낸다.
4. 서버는 클라이언트에서 받은 암호화 된 메시지를 public 키로 해석한 후 그 결과를 2단계에서 자신이 클라이언트에게 보낸 랜덤 챌린지와 일치하는지 확인한다. (public 키로 해석할 수 있는 메시지는 그 쌍이 되는 private 키를 가진 사람만이 만들 수 있기 때문) 일치하면 클라이언트가 인증된 것이다.

SSH 키 만들기

서버가 SSH 키 인증을 사용하도록 설정하려면 가장 먼저 해야 하는 일은 클라이언트에서 키 페어를 만드는 것이다.
키 페어를 만들려면 OpenSSH에 포함되어 있는 ssh-keygen 유틸리티를 사용한다. 디폴트로 2048-bit RSA 키 페어를 만들게 되어 있는데, 대부분의 사용자에게 이 정도면 충분하다.

클라이언트에서 ssh-keygen을 실행해 SSH 키 페어를 만든다.

$ ssh-keygen

Generating public/private rsa key pair.
Enter file in which to save the key (/home/test/.ssh/id_rsa):

프로그램이 생성될 키를 저장할 위치를 선택하도록 물어본다. 디폴트로 ~/.ssh 디렉토리에 저장하게 되어 있다. Private 키는 id_rsa라는 이름이고 public 키는 id_rsa.pub라는 이름을 사용한다. 일반적으로 디폴트를 그대로 사용하는게 좋다. 별도 디렉토리를 사용하려면 원하는 위치를 입력하고, 그냥 디폴트를 사용하려면 엔터를 누르면 된다.

만일 이전에 만들어 놓은 SSH 키가 있다면 다음과 같은 내용을 보게 될 것이다.

/home/test/.ssh/id_rsa already exists.
Overwrite (y/n)?

덮어쓰기를 선택하면 이전 키를 사용하는 인증은 더 이상 사용할 수 없게 된다. 이 단계는 되돌릴 수 없으므로 yes를 선택하려면 매우 주의해야 한다.

Created directory '/home/test/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

다음으로 키에 대한 passphrase를 물어본다. Passphrase는 옵션으로 private 키를 디스크에 저장할 때 암호화 하는데 사용된다.
어짜피 passphrase를 입력해야 한다면 SSH 키를 사용하는 장점이 무엇인가 궁금할 수 있을 것이다. 몇가지 장점을 나열하자면...

* Private SSH키(passphrase로 보호되는 부분)는 네트웍 상에 절대로 노출되지 않는다. Passphrase는 로컬머신상에서 private 키를 해석하는데만 사용된다. 그러므로 passphrase에 대한 네트웍 기반의 brute-force 공격이 불가능해 진다.
* Private 키는 제한된 디렉토리내에서만 보관된다. SSH 클라이언트는 제한된 디렉토리에 보관되지 않는 private 키는 인식하지 않는다. 또한 키 자체는 제한된 퍼미션을 가져야만 한다. (owner만 rw가 가능) 즉 시스템의 다른 사용자가 볼 수 없다는걸 의미한다.
* Private SSH 키의 passphrase를 탈취하려는 해커는 이미 시스템을 억세스 할 수 있어야 한다. 즉 해커가 이미 시스템의 사용자 어카운트나 루트 어카운트에 억세스 할 수 있다는걸 의미한다. 이 경우 passphrase를 사용하면 해커가 즉각 다른 서버에 로그인 하는걸 막아줄 수 있다. 즉 새로운 SSH key 쌍을 만들고 이미 탈취당한 키는 삭제할 수 있는 시간을 벌어줄 수 있다.

Private 키는 절대 네트웍에 노출되지 않고 파일 퍼미션으로 보호되기 때문에 당신(과 루트유저) 이외에는 이 파일에 접근할 수 없다.
Passphrase는 옵션이기 때문에 입력해주면 이후에는 (SSH agent를 사용하지 않는 한) 이 키를 사용할 때 마다 passphrase를 입력해 줘야 한다. Passphrase를 사용하는걸 권장하지만, 원하지 않는다면 그냥 엔터를 눌러주면 된다.

Your identification has been saved in /home/username/.ssh/id_rsa.
Your public key has been saved in /home/username/.ssh/id_rsa.pub.
The key fingerprint is:
a9:49:2e:2a:5e:33:3e:a9:de:4e:77:11:58:b6:90:26 username@remote_host
The key's randomart image is:
+--[ RSA 2048]----+
| ..o |
| E o= . |
| o. o |
| .. |
| ..S |
| o o. |
| =o.+. |
|. =++.. |
|o=++. |
+-----------------+

이제 인증에 사용할 수 있는 private 키와 public 키 쌍을 만들었다. 다음 단계는 public키를 서버에 넣어줘 SSH key를 인증에 사용할 수 있게 해 주는 것이다.

서버에 public 키를 카피하기 :: SSH-Copy-ID

서버에 public키를 복사하는 가장 쉬운 방법은 ssh-copy-id 라는 유틸리티를 사용하는 것이다. 간단하기 때문에 가능하다면 가장 권장하는 방법이다. ssh-copy-id는 OpenSSH 패키지에 들어있기 때문에 로컬 시스템에 이미 설치되어 있을 가능성이 크다. 이 방식을 사용하려면 먼저 서버에 패스워드로 ssh 억세스가 가능해야만 한다.

이 유틸리티를 사용하려면 연결하려는 원격 호스트 이름과 유저 어카운트를 지정해 주면 된다.

$ ssh-copy-id test@foo.bar.com

명령을 입력하면 다음과 같은 메시지가 출력된다.

The authenticity of host 'foo.bar.com (111.111.11.111)' can't be established.

ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.

Are you sure you want to continue connecting (yes/no)? yes

메시지의 내용은 로컬 컴퓨터가 원격 컴퓨터를 식별할 수 없다는 의미이다. 새 호스트에 처음으로 접속하는 경우 발생한다. 'yes'와 엔터를 눌러 계속 진행한다.

유틸리티가 로컬 어카운트의 기존에 만들어 놓은 id_rsa.pub 키를 찾는다. 키를 찾으면 원격 컴퓨터의 유저 어카운트 패스워드를 묻는다. (예에서는 foo.bar.com 서버의 test 어카운트의 암호)

/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed

/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys

test@foo.bar.com's password:

암호를 입력하고 엔터를 누르면 유틸리티는 입력한 암호를 사용해 원격 호스트의 어카운트에 연결한다. 그리고 로컬 어카운트에 있는 ~/.ssh/id_rsa.pub 키파일의 내용을 원격 호스트 어카운트의 ~/.ssh 디렉토리에 있는 authorized_keys 에 복사한다.

Number of key(s) added: 1

Now try logging into the machine, with: "ssh 'test@foo.bar.com'"

and check to make sure that only the key(s) you wanted were added.

이제 자신의 id_rsa.pub 파일이 서버에 업로드 된 것이다.

- 수동으로 복사

로컬 머신 어카운트의 id_rsa.pub 키 파일 내용을 SSH로 로그인하길 원하는 서버 어카운트의 ~/.ssh/authorized_keys 파일에 복사해 넣어주면 된다.

먼저 id_rsa.pub 키 파일 내용을 화면에 출력한다.

$ cat ~/.ssh/id_rsa.pub

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== test@localhost

원격 호스트에 로그인 한 다음 먼저 홈 디렉토리에 .ssh 디렉토리가 만들어 져 있는가 확인한다. 만일 없다면 다음 명령으로 만들어준다.

$ mkdir ~/.ssh

이제 .ssh 디렉토리 안에 authorized_key 파일이 없으면 만들고, 이미 존재하면 파일 내용에 추가해주면 된다.

$ echo [public_key_string] >> ~/.ssh/authorized_keys

위의 명령에서 빨간색 [public_key_string] 부분은 위의 cat 명령에서 출력된 결과로 바꿔줘야 한다. (위에서 노란색으로 칠해진 부분)

SSH 키를 사용해 서버에 로그인하기

서버에 public 키를 카피해 놓았다면 원격 호스트에 로그인 할 어카운트의 암호 없이 로그인이 가능하다. 로그인 절차는 완전 동일하다.

$ ssh test@foo.bar.com

만일 이 호스트에 SSH로 첫번째 접속하는 것이면 다음과 같은 메시지를 보게 될 것이다.

The authenticity of host 'foo.bar.com (111.111.11.111)' can't be established.

ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.

Are you sure you want to continue connecting (yes/no)? yes

Private 키에 passphrase를 지정해 주지 않았다면 곧바로 로그인이 된다. 만일 키 쌍을 만들 때 private 키에 passphrase를 지정해 주었다면 passphrase를 물어본다. 인증이 성공되면 쉘 세션이 열리게 된다.

Java 의 keystore에 SSL/TLS Server 인증서를 import 하는 방법

Steven J.S Min — Thu, 28 Feb 2019 15:44:16 +0900

SRC: 정광섭님, https://www.lesstif.com/pages/viewpage.action?pageId=12451848

증 상

Java 에서 HTTPS 로 remote 사이트에 연결시 다음과 같은 Exception 이 발생

error log

Caused by: javax.naming.CommunicationException: simple bind failed: <server-name>

[Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target\]

원 인

다음과 같이 여러 가지 원인이 있을 수 있다.

연결하려는 remote site의 인증서가 신뢰하는 인증기관 인증서 목록(keystore)에 없음
서버/클라이언트간 사용하려는 SSL/TLS 버전이 맞지 않음(Ex:TLS 1.0 만 지원하는 서버에 1.2로 hand shaking 요청등)
SSL/TLS 통신에 사용하려는 cipher suite 가 오래되거나 지원하지 않음. (Ex: JDK 1.8 부터는 RC4 를 사용하려고 하면 에러 발생)
웹 브라우저의 경우 인증서 경로 설정을 참고하여 웹 서버에 Intermediate CA certificate 를 설치한다.

무료 SSL 인증서를 발급해 주는 Let's encrypt 의 CA 인증서는 Java VM 에 포함되어 있지 않으므로 Let's encrypt 에서 발급 받은 SSL 인증서를 Java 에서 사용할 경우에도 위와 같은 에러가 발생한다.

해 결

1번 원인일 경우 현재 구동되는 JDK 의 keystore에 상대방 인증서를 넣어줘야 함

1. gist 에서 InstallCert.Java 를 다운로드

curl -O https://gist.githubusercontent.com/lesstif/cd26f57b7cfd2cd55241b20e05b5cd93/raw/InstallCert.java

InstallCert.java

2. 컴파일

javac InstallCert.java

3. InstallCert 구동

# localhost 에 SSL 인증서를 받아올 호스트명을 입력

java -cp ./ InstallCert git.nbnco.net.au

4. 다음과 같은 화면이 나오면 1을 눌러서 인증서 저장

ssl import

Caused by: java.lang.UnsupportedOperationException
at InstallCert$SavingTrustManager.getAcceptedIssuers(InstallCert.java:183)
at sun.security.ssl.AbstractTrustManagerWrapper.checkAlgorithmConstraints(SSLContextImpl.java:926)
at sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:872)
at sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:814)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1323)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:153)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:868)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:804)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1016)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339)
... 2 more

Server sent 2 certificate(s):

1 Subject CN=wiki.modernpug.org
Issuer CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US
sha1 47 0a 15 c4 5d ed 62 0a 4b 18 d5 d8 58 14 42 5d 36 e0 d5 8f
md5 3a 0d ab ce 27 be dd bd e5 c1 d5 e8 b6 25 aa eb

2 Subject CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US
Issuer CN=DST Root CA X3, O=Digital Signature Trust Co.
sha1 e6 a3 b4 5b 06 2d 50 9b 33 82 28 2d 19 6e fe 97 d5 95 6c cb
md5 b1 54 09 27 4f 54 ad 8f 02 3d 3b 85 a5 ec ec 5d

Enter certificate to add to trusted keystore or 'q' to quit: [1]
2

서버가 2 개의 인증서를 전송했는데 2번째가 Let's Encrypt 의 CA 인증서이므로 2번을 선택해서 저장해야 한다.

5. 다음과 같은 메시지가 나오고 저장됨. keystore 명과 alias 명을 기억

Added certificate to keystore 'jssecacerts' using alias 'letsencrypt'

6. keytool 로 keystore에서 인증서 추출 (KeyStore의 암호는 changeit 이라 가정!)

## alias 옵션뒤에 위의 alias명 입력
keytool -exportcert -keystore jssecacerts -storepass changeit -file output.cert -alias letsencrypt

-alias 옵션 뒤에 파라미터는 5번에서 저장된 alias(letsencrypt) 를 입력

7. 현재 JDK 의 keystore에 cert import

## JAVA_HOME=/usr/java/jdk1.7.0_25
keytool -importcert -keystore ${JAVA_HOME}/jre/lib/security/cacerts -storepass changeit -file output.cert -alias letsencrypt

이미 존재할 경우 다음 명령어로 삭제

keytool -delete -alias letsencrypt -keystore ${JAVA_HOME}/jre/lib/security/cacerts -storepass changeit

같이 보기

JMeter와 Performance 테스트

Steven J.S Min — Mon, 13 Aug 2018 16:05:48 +0900

Apache JMeter는 웹 애플리케이션처럼 클라이언트-서버 구조로 된 소프트웨어의 성능 테스트를 위해서 만들어진 100% 순수 자바 프로그램입니다. 스테파노 마조끼가 개발했으며, 이는 현재 톰캣(Tomcat)으로 이름이 바뀐 Apache JServ의 테스트를 위한 코드에서 시작됐습니다. 이후 이 코드에 GUI와 기능을 추가하여 JMeter가 만들어졌습니다.

JMeter는 단위/성능/스트레스 테스트 등 많은 곳에서 활용할 수 있습니다. 프로토콜(Protocol)도 계속 추가되어 TCP, HTTP(S), FTP, JDBC, LDAP, SMTP, SAP/XML, RPC 등 현재 범용으로 사용되는 프로토콜 대부분을 지원합니다.

JMeter는 통신 프로토콜 단계에서만 동작하고 웹 브라우저에서는 동작하지 않습니다. 즉, 통신규약에 맞도록 클라이언트와 서버 간 메시지만 송수신할 뿐이고 클라이언트 자체에서 행해지는 연산 동작은 하지 않습니다. 가장 대표적인 예가 ActiveX를 이용하여 암호화나 연산 작업을 하는 사이트입니다. 이러한 사이트는 ActiveX 로직을 모두 이해하고 자바를 이용하여 별도로 JMeter 내부 모듈을 구현하지 않는 이상 테스트가 불가능합니다.

JMeter는 2001년에 1.0을 발표한 후 10여년 동안 꾸준히 기능과 성능을 향상하여 2011년에는 Apache Software Foundation에서 Top Level Apache Project에 선정되기도 하였습니다. 또한, 자바 가상 머신(JVM, Java Virtual Machine)과 H/W의 성능이 향상되면서 초기에 문제가 되던 성능이나 기능 면에서 부족함이 많이 해소되어 현재는 웬만한 성능 테스트에서 핵심으로 활약하기에 부족함이 없는 상태에 도달한 것으로 보입니다.

기능이 다양하고 성능이 좋음에도 JMeter는 오픈소스라는 이유로 성능 테스트 현장에서 많이 활용되지 못하고 있는 것이 현실입니다. LoadRunner와 같은 외산 상용 솔루션이 가장 많이 사용되지만 라이선스 비용 문제로 현장에서 충분히 활용되지 못하며, 국내 몇몇 솔루션은 엔지니어 층이 얇거나 제대로 검증되지 않아서 신뢰성이 떨어지는 경우가 많습니다.

필자가 JMeter를 이용해서 많은 사이트의 성능 테스트를 진행하면서 도달한 결론은 불과 몇년 전만 해도 다소 부족했지만, 현재는 JMeter로도 대부분 사이트에서 원하는 테스트를 수행할 수 있으며 성능이나 기능 면에서 부족함을 느끼기 어렵다는 것입니다.

JMeter는 IT 업계에서 종사하는 엔지니어가 사용하기에 그리 복잡하지 않은 프로그램입니다. 하지만 이 프로그램이 테스트 환경과 결합하면 많은 변수를 고려해야 하는 상황이 발생합니다. 그 변수가 JMeter 자체 문제인지 네트워크 환경 문제인지 그리고 애플리케이션 서버 구성 또는 애플리케이션 자체 문제인지를 적절하게 구별하고 JMeter가 보여주는 결과 수치로 얼마나 의미 있는 값을 찾아내는가가 중요합니다.

이 책에서는 JMeter를 사용하는 기초적인 방법부터 실제 성능 테스트 과정에서 일어날 수 있는 문제점에 대한 해결 방안과 JMeter로 대용량 테스트 환경을 구축하기 위한 최적의 방법까지 설명합니다.

성능 테스트

JMeter를 시작하기 전에 성능 테스트에 대한 기본적인 지식을 알고 있는 것이 좋습니다. 이는 테스트를 계획하고 결과를 분석하는데 중요한 역할을 합니다.

이 책에서 말하는 '성능 테스트'란 서비스 및 서비스 시스템의 성능을 확인하기 위해서 실제 사용환경과 비슷한 환경에서 테스트를 진행하는 것을 말합니다. 이를 통해서 응답시간(Response Time)과 처리량(Throughput), 병목구간 등을 확인할 수 있고, 성능 테스트로 얻은 정보로 서비스나 서비스 시스템의 문제점을 확인하고 이를 개선(Tuning)하여 보완할 수 있습니다.

성능 테스트는 쓰임에 따라 다음과 같이 나뉩니다.

Load 테스트: 시스템의 성능을 벤치 마크하기 위한 테스트를 의미합니다. 이 테스트는 부하(Load)를 순차적으로 증가시키면서 응답시간이 급격히 증가하거나 더는 처리량이 증가하지 않거나 시스템의 CPU와 Memory 등이 기준값 이상으로 증가하는 등 비정상 상태가 발생하는 임계점을 찾아내고 이를 바탕으로 성능 이슈에 대한 튜닝과 테스트를 반복합니다.

Stress 테스트: 임계값 이상의 요청이나 비정상적인 요청을 보내 비정상적인 상황의 처리 상태를 확인하고 시스템의 최고 성능 한계를 측정하기 위한 테스트를 의미합니다.

Spike 테스트: 이 테스트는 예를 들어 빌딩에 화재 경보가 발생했을 때 빌딩에 있는 직원들이 동시에 안전한 장소를 향해서 이동할 경우 시간이 얼마나 걸리며 어떤 문제가 발생하는지를 테스트하는 것과 같습니다. 즉, 갑자기 사용자가 몰렸을 때 요청이 정상적으로 처리되는지 그리고 그 업무 부하(Workload)가 줄어들때 정상적으로 반응하지는지를 확인하기 위한 테스트를 의미합니다.

Stability 테스트 / Soak 테스트: 긴 시간 동안 테스트를 진행해서 테스트 시간에 따른 시스템의 메모리 증가, 성능 정보의 변화 등을 확인하는 테스트를 의미합니다. 짧게는 한두 시간부터 길게는 며칠동안 진행하기도 합니다.

단계	프로세스	내용
1	요구사항 분석	- 테스트 목적과 범위를 정하는 단계로, 효율적인 테스트를 위해서는 목적을 정확히 설정해야 합니다. - 구 시스템과 신규 시스템의 비교 테스트, 신규 시스템 오픈 전 사전 임계치 테스트, 장애 발생을 대비한 Failover-Failback 테스트 등 테스트 범위와 우선순위를 결정해야 합니다. 모든 서비스를 테스트하면 좋겠지만, 보통 서비스 개발이나 유지 보수 때는 테스트를 위한 시간이 그다지 충분하지 않습니다. 그러므로 중요도와 테스트 목적에 맞는 우선순위와 그 범위를 정합니다. - 범위가 정해지면 해당 시스템의 소프트웨어적인 구조와 하드웨어적인 구조를 분석합니다.
2	테스트 계획	- 언제, 누가, 어떤 방법으로, 어디서 테스트할 것인지 정하는 단계입니다. - 테스트 수행에는 많은 내/외부 인력이 필요하며 많은 준비사항이 있으므로 테스트 계획이 필수입니다. - 테스트에 필요한 인력과 역할도 존재합니다.
3	테스트환경 구축	- 테스트 단계 내에서 테스트 환경 구축을 언제 수행할지는 그리 중요하지 않을 수 있습니다. 자주 테스트를 수행하는 곳에서는 테스트 전용 서버팜(Serverfarm)이 이미 구성되어 있기 때문입니다. 요즘은 클아우드 환경의 테스트 팜을 구성하는 경우도 있습니다. - 테스트 환경을 구축할 때 가장 중요한 것은 부하발생기와 테스트 대상 서버 사이의 네트워크가 최단 구간 안에 존재하게 하는 것입니다. 중간에 많은 보안 장비와 스위치/라우터(Switch/Router) 등을 거치면 예상하지 못한 결과가 발생할 수 있습니다.
4	테스트 설계	- 테스트 절차 및 테스트 시나리오를 작성하고 테스트 케이스 작성 및 스크립트를 구현하며 테스트에 필요한 데이터 셋(Dataset)을 준비하는 단계입니다. - 테스트에 필요한 데이터 셋을 준비하는 과정은 상당히 중요합니다. 테스트에 필요한 충분히 많은 데이터가 준비되지 않는다면 의도하지 않은 결과가 나올 가능성이 높기 때문입니다. 예를 들어, 어떤 시스템에서 실제로는 DB의 I/O에 의해서 성능 저하가 발생한다고 가정했을 때, DB의 테스트 데이터가 충분히 입력되지 않고 접근 데이터가 고르지 않으면 실제 서비스 때보다 성능이 좋게 나올 가능성이 높습니다. 즉, 실제 환경과 비슷한 수준의 많은 데이터를 준비할수록 테스트 결과가 좀 더 실제 값과 비슷해집니다.
5	테스트 수행 및 결과 수집	- 작성된 스크립트로 실제 테스트를 수행하는 단계입니다. 테스트 수행은 크게 두 부분으로 나누어집니다. 1) Pre-Test: Main-Test 전에 스크립트가 제대로 작성되었는지, 테스트 환경(서버/네트워크/보안 시스템/외부 연동 등)과 준비된 데이터 셋에 문제가 없는지 확인하기 위한 테스트입니다. Main-Test에는 많은 인력이 투입되므로 Pre-Test가 정상적으로 이루어지지 않으면 많은 인력이 불필요하게 대기하는 상황이 발생할 수 있으니 사전에 꼭 수행해야 합니다. 2) Main-Test: 실제 테스트를 수행하는 단계로, 테스트 분석에 필요한 시스템 성능 자료를 수집합니다. 통합 SMS 솔루션이 있으면 OS의 CPU, Memory, I/O 등의 정보는 쉽게 수집할 수 있습니다. 그렇지 않다면 별도의 시스템 정보 수집 스크립트를 이용해서 수집해야 합니다. AP(Application Server)는 APM(Application Performance Management)과 같은 전용 모니터링 도구를 이용하면 많은 정보를 편리하게 수집할 수 있습니다.
6	테스트 분석	테스트 결과 자료와 시스템 성능 자료를 모아서 테스트 결과를 분석합니다. 분석된 자료를 통해서 성능에 영향을 미치는 문제점을 찾습니다.
7	문제점 수정 및 재테스트	테스트 분석에서 발견된 문제점을 개발팀(Development Team)이나 시스템 운영팀(System Engineering Team)에 전달하여 문제점을 수정하고 다시 한 번 테스트를 수행합니다.
8	결과 리포트 작성	테스트 리포트는 테스트 목적에 따라 해당 목적을 가장 잘 표현할 수 있는 방식으로 작성하는 것이 좋습니다. 요약 리포트와 상세 리포트를 분리해서 상세 경과를 필요로 하는 부서와 요약 결과만 필요로 하는 부서에 별도로 리포트를 제출하는 것도 좋은 방법입니다.

테스트 인력	역할
Test Leader(PM)	전체적인 테스트 계획, 목적 수립, 시나리오 작성, 일정 관리와 인력 배치를 담당합니다.
Test Scripter(Designer)	정의된 테스트 목적 및 범위에 따라 작성된 시나리오로 사이트(서비스)를 분석하고 이를 바탕으로 상세 케이스를 작성합니다.
Team Operator	작성된 테스트 스크립트를 이용해서 실제 테스트를 수행합니다.
Development Team	테스트에 필요한 데이터를 준비하고 애플리케이션을 모니터링하며 발견된 문제점과 개선점을 찾아냅니다.
	테스트 환경을 구축하고 시스템(OS, 네트워크, 스토리지 등)을 모니터링하여 발견된 문제점과 개선점을 찾아냅니다.

대용량 성능 테스트

이 책에서 의미하는 '대용량 성능 테스트'란 매우 많은 가상 사용자(Virtual User, Thread)가 필요한 테스트나 매우 높은 웹 트랜잭션 처리량을 테스트하는 것을 의미합니다. 즉, 대규모 장비가 필요한 테스트입니다. 대용량 성능 테스트를 진행하다 보면 결과에 많은 영향을 주는 요소들이 발생합니다. 이것은 현재 수행한 테스트 결과가 믿을만한지, 어떤 요소가 한계점에 다다라서 결과가 왜곡되지 않았는지에 대한 고민에 빠지게 합니다. 예를 들어, 여러 대의 부하발생기가 연결되면 부하발생기의 네트워크 구성에 따라 결과가 달라질 수 있으며, 애플리케이션 서버의 능력보다 네트워크 스위치의 성능이나 OS 설정값에 의해 결과가 매우 달라질 수 있습니다.

그러므로 좀 더 신뢰성 높은 결과값을 얻기 위해서는 결과에 영향을 미치는 요소들을 최대한 제거해야만 합니다. 이책에서는 기본적은 JMeter의 사용법과 함께 대용량 성능 테스트를 수행할 때 발생할 수 있느 문제점과 그에 대한 해결 방법을 실무에서 겪은 다양항 경험과 시행착오를 바탕으로 테스트 담당자들이 이런 시행착오를 겪지 않도록 하기 위한 팁과 노하우를 다룹니다. 또한, 이를 바탕으로 테스트의 신뢰성을 높이고 테스트 결과값에서 의미있는 내용을 찾는 방법을 설명합니다.

주요 용어 및 개념

성능 테스트와 관련하여 자주 사용되는 용어와 그 개념을 간략하게 정리해 보겠습니다.

Active User: 실제 서버에 연결된 상태로 요청을 처리 중인 사용자를 말합니다.

InActive User: 웹브라우저에 결과 화면이 출력된 상태에서 화면의 내용을 읽거나 정보를 입력하고 있는 사용자입니다. 서버와의 세션(Session) 정보를 가지고 있지만 직접 접속하여 요청을 주고받는 상태가 아닌 사용자를 의미합니다.

Concurrent User(Active User + InActive User): 보통 '동시 접속 사용자수'라고 표현합니다. 일반적으로 사용자 수의 많고 적음을 표현하는 값으로, 성능 테스트에서 가상 사용자 수를 결정하는 기준이 됩니다. 서비스 유형과 시간에 따라 그 비율이 달라지긴 하지만, 일반적으로 Active User와 InActive User 비율이 1:10 정도입니다.

Virtual User: 가상 사용자 수로, JMeter에서는 Thread 수로 표현하기도 합니다.

Ramp-Up Period: Thread(Virtual User) 생성에 걸리는 시간을 의미합니다. Ramp-Up Period를 이해하기 쉽도록 작성한 그래프입니다.

이 그래프는 '10개의 Thread를 50초 동안 차례대로 생성하라'는 의미입니다. 즉, 5초(50초/10개)마다 Thread를 하나씩 생성하는 것과 같은 의미입니다.

Throughput: 단위 시간당 대상 서버(웹서버, WAS, DB 등)에서 처리되는 요청의 수를 말합니다. JMeter에서는 시간 단위를 보통 TPS(Transaction Per Second)로 표현합니다.

Response Time/Load Time: 응답시간 또는 처리시간이라고 표현합니다. 요청을 보낸 후 응답이 완료되어 사용자 화면에 출력될때까지의 시간을 나타냅니다. 시스템의 성능을 평가하는 지표로 주로 사용됩니다.

Latency: 요청을 보낸 후 데이터를 받기 시작할 때까지 시간입니다.

Think Time: 하나의 요청에 응답을 수신하고 다음 요청을 보낼 때까지 시간을 의미합니다. 테스트에서 실제 사용자의 사용패턴과 유사한 패턴을 구현하기 위해서는 이 Think Time을 적절히 적용해야 합니다.

Request Interval Time: 요청을 보낸 후 다음 요청을 보낼때까지 시간을 의미합니다.

Load Time vs Latency: 아래 그림은 Load Time/Latency/Think Time/Request Interval Time의 관계를 이해하기 쉽도록 그림으로 나타낸 것입니다.

위를 보면 한상 Load Time >= Latency가 성립됩니다. 두 개를 왜 나눠놓았을 까요? 이것은 Latency와 Load Time을 구분함으로써 성능을 분석할 때 요긴하게 사용할 수 있습니다.

A와 B 사이트에 동일한 크기(10MB 정도)의 파일을 올려놓고 다운로드 테스트를 진행한다고 가정해보겠습니다. A 사이트와 B 사이트의 결과를 비교해 보니 B 사이트의 Load Time이 2배 이상 컸습니다. 하지만 Latency는 거의 비슷했습니다. 이렇게 차이가 나는 이유가 무엇일까요?

Load Time에서 Latency를 빼면 데이터를 전송받는데 걸리는 시간을 나타냅니다. 즉, B 사이트가 A 사이트보다 데이터를 내려받는 속도가 느리다고 볼 수 있습니다. 따라서 B 사이트는 처리량을 늘리기 위해 웹서버를 튜닝하기보다는 네트워크의 대역폭(Bandwidth)을 늘리는 것을 고려해야 합니다.

출처: http://12bme.tistory.com/272 [길은 가면, 뒤에 있다]

Tomcat 서버를 자동으로 Startup 하기 On Amazon Linux

Steven J.S Min — Mon, 18 Jun 2018 10:13:49 +0900

이 페이지에서는 Tomcat상에 설치된 Jenkins를 서버구동시에 자동으로 시작되도록 하는 방법을 설명합니다.

테스된 환경설정은 다음과 같습니다.

OS : Amazon Linux
Tomcat : 8
Java : 8
CATALINA_HOME 디렉토리 : /local/tomcat
CATALINA_BASE 디렉토리 : /local/tomcat-jenkins

Tomcat 은 CATALINA_HOME(Tomcat 엔진이 설지된 위치), CATALINA_BASE(어플리케이션 별로 사용될 Tomcat Instance용 디렉토리) 디렉토리를 분리해 설정했습니다.

'/etc/init.d/jenkin.sh' 파일 작성

#!/bin/bash

### BEGIN INIT INFO

# Provides: jenkins

# Required-Start: $network

# Required-Stop: $network

# Default-Start: 2 3 4 5

# Default-Stop: 0 1 6

# Short-Description: Start/Stop Jenkins server

### END INIT INFO

export TOMCAT_SERVER_NAME="jenkins-master"

CUR_DIR="/local/tomcat-jenkins"

export JAVA_HOME=/local/jdk

export CATALINA_HOME=/local/tomcat

export CATALINA_OPTS="-Denv.servername=${TOMCAT_SERVER_NAME}"

export CATALINA_BASE="${CUR_DIR}"

export CATALINA_TMPDIR="${CUR_DIR}/temp"

export CATALINA_OUT="${CUR_DIR}/logs/catalina.out"

export CATALINA_PID="/var/run/${TOMCAT_SERVER_NAME}.pid"

start() {

sh /local/tomcat/bin/startup.sh

}

stop() {

sh /local/tomcat/bin/shutdown.sh

}

*** 만일 서비스 구동시 특정 지정된 사용자를 이용해서 구동해야 하는 경우 다음과 같은 쉘 커맨드 형식을 Start와 Stop 함수에 사용합니다.

다음의 예제는 tomcat서비스를 "jenkins" 사용자로 구동하는 예제입니다.

start() {

su -c "/opt/tomcat/bin/startup.sh" jenkins

}

stop() {

su -c "/opt/tomcat/bin/shutdown.sh" jenkins

}

권한 변경 및 Check config 에 등록 for Auto start on boot up

Shell> chmod 755 jenkins

Shell> chkconfig jenkins on

Service command 를 이용한 Start, Stop, Restart

Shell> service jenkins start

Shell> service jenkins stop

Shell> service jenkins restart

Auto start 서비스에 등록된 정보를 확인 하고자한다면

Shell> chkconfig --list jenkins

AMI vs. EC2 vs. Volume vs. Snapshot

Steven J.S Min — Mon, 18 Dec 2017 12:56:56 +0900

가끔 블럭 디바이스와 EC2, AMI와의 관계와의 내용이 명확하지 않아 이들 서비스간의 내용을 정리해 봅니다. 프로그래밍으로 따지자면 클래스와 객체정도로 비유 될수 있을텐데요, 이미지들을 테스트나 개발 계정에서 테스트하고 배포하기위하여 이미지를 프로모션하는 경우 이러한 관계를 명확히 하지않으면 인프라 코딩이 어려워 질수있다는 경험을 하였습니다.

AMI

AMI의 가장중요한 역할중 하나는 EC2 Instance를 생성하는 Base이미지 역할을 하는것이라고 할수 있습니다.

또한 이 AMI는 AWS로부터 제공되는 이미지를 사용할수있지만, 회사 조직내에서 미리 준비된 AMI를 생성할수도 있습니다. 이때 조직내에서 AMI를 생성하였다면 AMI는 어떤 Block디바이스(즉 디스크)와 마운트 될것인지 정보를 자체적으로 포함하고있기 있을겁니다. 이런 경우 지정된 Block디바이스(AMI에서 사용될 디스크)는 Snapshot으로 만들어져 보관되어 집니다. (이런경우 Snapshot을 지우려고 하는 경우 삭제할수 없다는 오류 메시지가 뜹니다.)

역으로 종종 Snapshot으로부터 AMI를 다른 계정에 생성해야하는 경우가 생기는데 이경우 복사하고자 하는 AMI가 어떤 블럭디바이스(Snapshot)를 사용하고 있는지 조사해서 해당 Snapshot도 복사(또는 공유)해줘야 합니다.

EC2

EC2인스턴스를 생성할때 반드시 하나이상의 블럭 디바이스를 지정해야하는데 Root디바이스는 필수이기 때문입니다. 그밖에 추가로 마운트될 디바이스를 지정하는 경우 추가로 Volume이 생성되기도 합니다.

이렇게 생성된 EC2인스턴스는 역으로 AMI를 생성해 둘수가 있는데 이때 사용되었던 Block디바이스가 있었다면 AMI에 자동으로 추가할 것인지 물어보지만, 원하지 않는경우 빼버리거나 블럭디바이스의 Encrypt옵션도 추가해서 저장할 수 있습니다.

Volume/Snapshot

볼륨은 현재 서버(EC2 인스턴스)에서 사용하고있는 디스크와도 같습니다. 이 디스크(편의상)는 특정시점에 Snapshot 형태로 분리하여 저장할수도 있고, 역으로 Snapshot으로부터 서버에서 사용할수 있(마운트가능한)는 형태의 디스크로 생성할 수도 있습니다.

Snapshot

이미 Snapshot에 대해 설명했지만, 흥미로운 점은 Snapshot으로 부터 AMI를 생성할 수도 있다는 겁니다. 일반적으로 EC2로부터 AMI를 생성하는 것이 여러면에서 쉽지만 종종 Snapshot으로 부터 AMI를 생성해야 하는 경우가 발생 할 수 있습니다.

그러면 EC2 인스턴스로부터 AMI를 생성하는 것과 Snapshot으로부터 AMI를 생성하는 경우 무엇이 다를까요?

EC2 인스턴스로부터 AMI를 생성하는 경우 위에서 이미 설명했지만, Snapshot으로부터 AMI를 생성하는 경우 지정된 Snapshot이 Root디바이스로(Volume)(만) 지정된다는 겁니다.

즉, EC2 인스턴스로부터 AMI를 생성하는 경우 이미 현재 EC2 인스턴스가 사용되고있는 디스크들을 찾아서 AMI로 만들것을 추천하지만 Snapshot으로부터 AMI를 생성하는 경우 그렇게까지는 해주지 않는 다는 차이점이 있습니다.

** Snapshot은 내부적으로 S3로 저장된다고 문서에서 설명하고 있습니다.실제로 블럭디바이스를 사용하지 않는 Volume형태로 남겨 두는 경우 개인 계정을 개설하는 경우 요금이 생각보다 저렴하지 않을수 있으므로 Snapshot형태로 저장하도록 합시다. 본인의 경우 개인계정에서 인프라코드를 통해서 EC2 서버를 계속생성하고 테스트후 삭제하였는데도 불구하고 요금이 엄청나온적이 있습니다. 주된 과금이유는 바로 이러한 Volume을 삭제하지않은채로 놔뒀기 때문이었습니다.

AWS EFS 설정

Steven J.S Min — Fri, 28 Jul 2017 10:15:03 +0900

EFS는 EBS볼륨과 가장 많이 다른점은

동일한 Region내(그리고 동일한 VPC네트웍 내에서) AZ에 상관없이 마운트가 가능합니다.

그리고..

Network File System V4(NFSv4)를 지원
Petabytes 스케일업

등을 지원합니다.

일단 EFS를 생성하면 생성시 지정된 어베일어빌리티전(AZ)에 저장하고, Mount Target에는 EFS에서 제공된 DNS를 통해 마운트합니다.

이상은 일반적인 메뉴얼에 있는 내용입니다.

실제 프로젝트에서 적용하면서 이슈가 되는 몇가지 내용을 정리해봅니다.

1. Security Group의 적용에 관하여

보통 일반 메뉴얼은 기본적으로 제공되는 (VPC) Default Security Group을 적용하는것으로 가이드 되어있습니다.

기본적으로 제공되는 SG는 소스에 자기자신이 지정되어 self-referential로 설정되어있습니다.

이것은 해당 SG가 적용된 리소스로부터는 어느 Source이든 지정된 트래픽과 프로토콜을 허용하겠다는 것입니다.

(기본 SG는 All traffics, All Types 으로 되어있습니다.)

EFS를 운용하다보면 가끔 특별한 제어가 필요할때도 있기때문에 우선 기본SG와 동일한 SG를 적용해서 인스턴스와 EFS에 적용하는것이 좋습니다.

2. EFS 마운트

서버가 시작되면 그때마다 마운트해서 사용해도 되겠지만

/etc/fstab 에 추가 지정하여 자동 마운트 되도록 사용할 수있습니다.

$> vi /etc/fstab

fs-89f514b0.efs.ap-southeast-2.amazonaws.com:/ /root/share nfs4 nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,_netdev 0 0

** fs-89f514b0.efs.ap-southeast-2.amazonaws.com:/ 는 EFS에서 제공도는 DNS입니다.

** /root/shar는 마운트되는 디렉토리입니다.

3. EFS 언마운트

$> mount --> 현재 마운트되어있는 목록을 보여줍니다.

$> umount fs-89f514b0.efs.ap-southeast-2.amazonaws.com:/

EFS의 개인적인 느낌은 다음과 같은 경우를 제외하면 EFS 보다는 EBS 볼륨을 사용하는 것이 좋을것 같다는 생각을 합니다.

EBS가 유용 한 경우.

- AZ 제약없이 하나이상의 서버가 공유가 필요한 디렉토리가 필요한경우

- 아마존 이외에 기존의 데이터센터에서 Amazon으로의 네트웍드라이브가 필요한 경우

Grace Period /Scaling Cooldowns on AWS AutoScaling & Stress 테스트

Steven J.S Min — Thu, 27 Jul 2017 20:37:06 +0900

AWS에서의 Scaling은 처음에 설정해보고 테스트해보면 그 편리성과 예전과는 비교할수 없을만큼 용이함에 모든것이 이해된것 처럼 생각되지만, 막상 프로젝트에서 이를 구현하다보면 기본 개념이 정리되지 않아서 그 문제를 찾기 어려운 경험이 있었습니다. 다시한번 쭉 살펴보면서 몇가지 정리해 보았습니다.

AutoScaling 설정은 보통 다음과 같은 과정을 거치게됩니다.

1. AutoScaling 그룹에서 사용할 템플릿(Configurtion)을 정의

: 개발 인스턴스 설정하는 것도 거의 동일합니다.

- 어떤 형태의 인스턴스를 사용할것인지 선택 : 리눅스종류, 스토리지, SecurityGroup, 사용할키페어

- IAM Role 지정

2. 정의된 템플릿을 이용하여 AutoScaling Group 정의

- 몇개의 인스턴스부터 시작할것인지

- Scaling될 AZ들 선택

- 임계치설정

- 인스턴스를 어떤 경우에 증가 할 것인지

- 인스턴스를 어떤 경우에 감소 시킬 것인지

- 이미 운영중에도 대부분의 임계치 값을 변경시킬수 있습니다.

나의 경우 그 동안 몇가지 개념때문에 트러블슈팅에 애를 먹은 경험이 있는데, 아래 임계치 설정에대한 개념의 좀 부족했던것 같습니다.

Health Check Type :

EC2 - Amazon EC2에서 제공한 상태 확인 (기본)

ELB - Elastic Load Balancing에서 제공한 상태 확인

Health Check Grace Period :

AutoScaling을 하는 입장에서는 해당 인스턴스의 상태를 체크해서 리소스를 늘려야할지 줄여야할지 판단해야하는데

이때 언제 이 상태를 체크하느냐가 문제가 될수있습니다.

일단, AutoScaling이 작동하기 위해서는 인스턴스가 InService상태가 될까지는 기다려야 합니다.

Health Check Grace는 ELB로부터 Health Check를 받고 얼마만큼 기다려야하는가와 관련이 있습니다.

보통은 그래서 어플리케이션이 구동되는데 3분이 걸리면 최소한 180초(3분)를 잡으라고 되어있지만,

실상 이것은 ELB에서 Health체크의 임계값에 따라 결정되어야하며

Healthy인지 Unhealthy인지 Threshold값과 Interval 설정을 고려해서 설정해야 하겠습니다.

증상 : 이러한 소요기간보다 Health Check Grace를 적게잡으로 의도하지 않게 서버서비스가 올라올때 이미 서버가 ScaleUp되어있는 현상이 있을수있습니다.

Scaling Cooldowns :

Health Check Grace Period와 약간 혼동스러운 부분이 있는데, 인스턴스 상태값(Not ELB)을 체크하여 AutoScaling 스케일작업을 결정할때 일반적으로 서버가 시작되도 어플리케이션 구동(예를들어 무거운 WAS서버등)의 준비 시간이 필요하기 때문에 이러한 추가 시간을 설정해주도록 해서 이러한 조정작업을 중지하도록 조치 할수 있습니다.

http://docs.aws.amazon.com/autoscaling/latest/userguide/Cooldown.html

http://docs.aws.amazon.com/autoscaling/latest/userguide/healthcheck.html

어떻게보면 AuotoScaling 자체가, 시스템의 성능보다는 신뢰성을 높이는데 촞점이 맞추어져있지만, 고객이나 엔드유저 입장에서는 이러한 임계값간의 Gap으로 인하여 성능에관한 이슈로 발전 될 수도 충분히 있습니다. 이러한 임계값을 최적화 하므로서 이러한 이슈를 최소화 할 수 있다고 봅니다.

요즘 경량화된 컨테이너 사용으로 베이스이미지를 사용하는 경향이 있는데...그리도 서버를 프로젝트에 맞게 프로비저닝하는 시간도 무시할수 없습니다. 완전한 베이스 이미지로부터 프로비저닝하기보다는 프로젝트에 최적화된 기본 베이스를 더 적극 활용하므러서 이러한 Threshold간의 Gap을 줄일수 있는 포인트라 할수 있겠습니다.

Stress Tool 사용

AutoScaling을 설정을 하다보면 설정한 환경이 의도대로 작동하는지 테트해 봐야겠지요.

이런 경우 간단히 사용할수 있는 stress 사용을 정리해보았습니다.

(이왕이면 htop과 같은 툴도 같이 설치하면 OS레벨에서 실제 변화되는 수지를 확인하면서 AWS가 어떻게 반응하는 확인이 더 수월하겠습니다.)

1개 core CPU에 60초가 부하테스트

$> stress -c 1 -t 60

4개 core CPU에 60초가 부하테스트

이때 예를 들어 코어가 1개라도 4개를 지정하여 실행하면 X4배 만큼 부하를 주게됩니다.(프로세스 4개 생성)

$> stress -c 4 -t 60

256M(메로리를 지정하지 않으면) X 3 를 소비하는 60초간 부하 즉 256M를 소비하는 3개의 프로스가 부하를 주게됩니다.

$> stress -m 3 -t 60

300M X 2를 소비하는 60초간 부하

$> stress -m 2 --vm-bytes 300M -t 60

1G(기본값)의 2개의 프로세스로 Disk 60초간 테스트

$> stress -d 2 -t 60

512M의 2개의 프로세스로 Disk 60초간 테스트

$> stress -d 2 --hdd-bytes 512M -t 60

CPU, Memory 그리고 Disk에 모두 테스

$> stress -c 4 -m 2 -d 1

AWS CLI 설치 On CentOS7

Steven J.S Min — Wed, 26 Jul 2017 18:38:00 +0900

Amazon Linux가 아닌 일반 머신에서는 반복적으로 AWS CLI를 설치하게되는데요, 그 과정을 단순히 정리해봅니다. RHEL계열은 아래과정과 대동소이하며, Debian계열의 Linux에서도 거의 비슷합니다.

우선 Python이 설치되어 있다고 가정합니다.

전체적인 과정

먼저 Python 패키지관리자인 PIP을 설치해줘야합니다.
Python Packaging Authority에서 제공하는 스크립트를 사용하여 pip를 설치한 다음 AWS CLI를 설치합니다.

wget이나 curl을 이용해서설치스크립을 다운로드.

$> curl -O https://bootstrap.pypa.io/get-pip.py

Python으로 다운로드 받은 파일을 실행합니다.

$> python get-pip.py --user

설치된 패키지를 영구히 등록하려면 "./.local/bin"를 PATH에 추가 등록합니다.

$> export PATH=$PATH:./.local/bin

pip이 정상적으로 설치되었는지 다음과 같이 확인해 봅니다.

$> pip --version

이젠 pip으로 AWS CLI를 설치합니다.

$> pip install awscli --upgrade --user