OpenStack2019.05.28 22:44

Hello, My friends who visit to my blog.

 

How have you been these days? In my case, I have been working OpenStack project nowadays. so I am very busy and tired now. Actually, I wanted to post in English on my blog continue. but I have to had solving the virous problems everyday and everytime. so I didn't have any time for posting in English on my blog.

 

Today, I will share about how to design OpenStack for security before I forget that I get my OpenStack experiance. 

I visited openstack.org site for checking OpenStack deployment methods. and I discoverd OpenStack architecture is changed. Now OpenStack is not using only virtual machines. We can use various resources like bare metal, virtual machines and containers.

What is OpenStack?

So how can we use our cloud resources more security? Openstack use REST API for using cloud resources. So it have http or https uri. Https is hypertext transfer protocol over secure. So https encrypted session data through ssl or tls protocol. ssl is secure socket layer. It needs certificate and secure key like below diagram.

 

Most OpenStack environment configured in data center. so it need many servers and there are many servers. Therefore we need to manage a lot of server's secure key and certification. How can we manage these keys and certifications?

 

Red Hat Openstack 13 can install ssl/tls using IDM server. IDM Server provides to manage users, domains, certificates and servers. For using ssl/tls with IDM Server, it needs domain of all Openstack  networks like below architecture.

Everywhere SSL/TLS with IDM Server

It has installed openstack packages in the director nodes. The packages are for installing openstack to other baremetal nodes. Let's see the process. 1. First, the director node registered domain to the IDM server. 2. And director will install controller and compute nodes with IDM server. 3. IDM server will check domain of overcloud's nodes and give the certificate to overcloud nodes.

 

If it finish to install openstack by director node, its system architecture is like below.

Nowadays OpenStack System Architecture

IDM server has apache httpd, ntp, dns, kerberos KDC, certmonger and SSSD(System Security Service Daemon)

Theses services provides features about manage overcloud nodes, domains, certificates and etc.

Director has openstack packages for overcloud(openstack for service) and docker. Because Openstack 13 version(queens) changed overcloud components. Previous openstack was installed only packages. Nowadays openstack main services are working in docker container.

If it install OpenStack with everywhere SSL/TLS, users can access by https based external network only. And each services can communicate with SSL/TLS only. The resources of OpenStack must certify by Keystone. If the certification is succesful, users can use OpenStack services. Also all networks of OpenStack isolated by network purpose. so If we design like below network, this OpenStack services will be secure. 

How to connect OpenStack Resources

How is this posting? If you have any opinion, please let me know it.

If I have free time, I will post about docker containers of openstack. 

Posted by 나리 짱!!! naleejang
OpenStack2019.05.10 17:59

오늘은 지난 포스팅에 이어 이번에는 Amphora 인스턴스를 한번 파헤쳐볼까 합니다. 지난 포스팅에서 보았던 Amphora 인스턴스에 대한 아키텍처를 혹시 기억하시나요? 지난 포스팅에서 저는 Octavia가 뭔지? 그리고, Octavia를 이용하여 로드밸런서 생성까지 해보았습니다. 그때 테스트로 미리 생성해 둔 10.10.10.0/24 대역의 인스턴스들을 기억하시나요? 해당 설정을 적용하여 다시 그려본 아키텍처가 아래 그림입니다.

 

 

## How to connect octavia amphora instance

시스템을 운영하다보면 가끔 때로는 인스턴스에 직접 들어가 시스템 상태를 체크해야 할 경우가 종종 있습니다. 그때를 대비해서 시스템에 어떻게 접근을 하는지 알고 있다면 참 많은 도움이 되겠죠!!

 

Amphora 인스턴스에 접속을 하기 위해서는 우선 인스턴스에 접속하기 위한 고정 IP주소와 액세스를 하기 위한 ssh key가 필요합니다. IP주소는 대쉬보드의 인스턴스 목록에서 172.24.0.0 대역의 IP를 확인 할 수 있습니다. 앞에서 만든 인스턴스의 고정 IP 주소는 172.24.0.23이였습니다. 그리고, 필요한것은 ssh key입니다. 레드햇 오픈스택은 TripleO라는 배포 노드를 통해 오픈스택을 설치하는데 이때 설치과정에서 Octavia가 사용할 network, flavor, amphora image, security group, ssh key를 만들어 줍니다. 이때 사용되는 ssh key는 배포 노드의 stack 계정에 생성되어진 ssh public key와 private key를 사용합니다. 그러니 ssh key는 배포 노드의 stack 게정에 생성된 ssh private key를 컨트롤러 노드에 복사하면 되겠죠!!

 

1. 그럼, 복사한 ssh key를 이용하여 아래와 같이 amphora 인스턴스에 접속할 수 있습니다.

[heat-admin@con1 ~]$ ssh -i octavia_key cloud-user@172.24.0.23

The authenticity of host '172.24.0.23 (<no hostip for proxy command>)' can't be established.

ECDSA key fingerprint is SHA256:+R8/b/0Kc9LXoezkoCWDV7niPPjy/RLsNeJk5dPeBsg.

ECDSA key fingerprint is MD5:97:f5:87:b6:6c:aa:1c:82:7f:72:0e:2f:4a:5f:21:fa.

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

Warning: Permanently added '172.24.0.23' (ECDSA) to the list of known hosts.

[cloud-user@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf ~]$ 

 

2. Amphora 인스턴스에 접속을 했습니다. 우선, 먼저 IP를 확인해 보겠습니다. 네트워크 디바이스는 eth0 하나이고, 고정IP 주소를 통해 들어온 172.24.0.23이 설정되어 있는것을 확인할 수 있습니다. 

[cloud-user@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf ~]$ ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

       valid_lft forever preferred_lft forever

    inet6 ::1/128 scope host

       valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

    link/ether fa:16:3e:01:c3:59 brd ff:ff:ff:ff:ff:ff

    inet 172.24.0.23/16 brd 172.24.255.255 scope global noprefixroute dynamic eth0

       valid_lft 65661sec preferred_lft 65661sec

    inet6 fe80::f816:3eff:fe01:c359/64 scope link

       valid_lft forever preferred_lft forever

[cloud-user@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf ~]$

 

3. 이번에는 프로세스 목록을 확인해 보겠습니다. 프로세스 목록에서 우리는 amphora-agent가 실행이 되고 있고, haproxy 가 실행되고 있는것을 확인할 수 있습니다.

[cloud-user@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf ~]$ ps -ef

UID        PID  PPID  C STIME TTY          TIME CMD

...

root      3180     1  0 Apr22 tty1     00:00:00 /sbin/agetty --noclear tty1 linux

root      3181     1  0 Apr22 ttyS0    00:00:00 /sbin/agetty --keep-baud 115200 38400 9600 ttyS0 vt220

root      3184  2844  0 Apr22 ?        00:00:29 /usr/bin/python2 /usr/bin/amphora-agent --config-file /etc/octavia/amphora-agent.conf

root      3188     1  0 Apr22 ?        00:00:00 rhnsd

root      3191  2844  0 Apr22 ?        00:00:00 gunicorn: worker [gunicorn]

root      3234     1  0 Apr22 ?        00:00:00 /usr/sbin/sshd -D

root      3667     1  0 Apr22 ?        00:00:00 /usr/sbin/haproxy-systemd-wrapper -f /var/lib/octavia/aabe2b08-ebcb-4243-b411-33c24ecca342/haproxy.cfg -f /var/lib/octavia/haproxy-default-user-group.conf -p /var/lib/oct

nobody    3795  3667  0 Apr22 ?        00:00:00 /usr/sbin/haproxy -f /var/lib/octavia/aabe2b08-ebcb-4243-b411-33c24ecca342/haproxy.cfg -f /var/lib/octavia/haproxy-default-user-group.conf -p /var/lib/octavia/aabe2b08-eb

nobody    3796  3795  0 Apr22 ?        00:00:16 /usr/sbin/haproxy -f /var/lib/octavia/aabe2b08-ebcb-4243-b411-33c24ecca342/haproxy.cfg -f /var/lib/octavia/haproxy-default-user-group.conf -p /var/lib/octavia/aabe2b08-eb

...

cloud-u+ 16522 16503  0 01:17 pts/0    00:00:00 ps -ef

[cloud-user@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf ~]$

 

4. 그럼, VIP는 어디에 설정이 되어 있는걸까요? 우선, sudo 명령어를 이용하여 root 계정으로 전환한 후 ip netns 명령어를 이용하여 가상 네트워크를 확인해 보겠습니다. 가상 네트워크 목록에는 amphora-haproxy라는 가상 네트워크가 생성되어 있는걸을 확인할 수 있습니다.

[cloud-user@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf ~]$ sudo -i

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf ~]# ip netns show

amphora-haproxy (id: 0)

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf ~]#

 

5. 가상 네트워크의 환경설정 정보를 확인해보면 아래와 같이 eth1이라는 가상 네트워크 디바이스와 인스턴스 목록에서 확인되었던 IP, 그리고 로드밸런서의 VIP를 함께 확인할 수 있습니다. VIP는 바로 여기 숨어 있었습니다. 

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf ~]# ip netns exec amphora-haproxy ip a

1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

    link/ether fa:16:3e:6d:d2:69 brd ff:ff:ff:ff:ff:ff

    inet 10.10.10.5/24 brd 10.10.10.255 scope global eth1

       valid_lft forever preferred_lft forever

    inet 10.10.10.13/24 brd 10.10.10.255 scope global secondary eth1:0

       valid_lft forever preferred_lft forever

    inet6 fe80::f816:3eff:fe6d:d269/64 scope link

       valid_lft forever preferred_lft forever

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf ~]#

 

6. 그럼, 이번에는 haproxy 모듈의 환경설정 파일을 살펴보도록 하겠습니다. 앞에서 이미 프로세스 목록을 확인했습니다. 그리고, 프로세스 목록을 통해 haporxy 환경설정 파일이 어느 디렉토리에 위치하는지를 확인했습니다. 확인된 디렉토리에 들어가 ls 명령어를 이용하여 파일 목록을 확인해 보면 아래와 같이 UUID와 같은 디렉토리명과 conf 파일 하나를 확인할 수 있습니다. conf 파일을 내용을 확인해 보니 특별한 내용은 없는듯 합니다.

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf ~]# cd /var/lib/octavia/

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf octavia]# ls

3c22219d-7c34-48f3-acf6-6e15f76ec9a1        haproxy-default-user-group.conf  plugged_interfaces

3c22219d-7c34-48f3-acf6-6e15f76ec9a1.sock  ping-wrapper.sh                  plugged_interfaces.sorted

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf octavia]# cat haproxy-default-user-group.conf

global

    group haproxy

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf octavia]# 

 

7. UUID와 같이 보이는 디렉토리로 들어가서 파일 목록을 확인해 보면 haproxy.cfg라는 환경설정 파일을 확인할 수 있습니다.

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf octavia]# ll

total 24

drwxr-xr-x. 2 root root 4096 Apr 22 21:28 3c22219d-7c34-48f3-acf6-6e15f76ec9a1

srw-rw-rw-. 1 root root    0 Apr 22 21:28 3c22219d-7c34-48f3-acf6-6e15f76ec9a1.sock

-rw-r--r--. 1 root root   25 Jan 10 10:32 haproxy-default-user-group.conf

-rwxr-xr-x. 1 root root  209 Jan 10 10:32 ping-wrapper.sh

-rw-r--r--. 1 root root   23 Apr 22 21:26 plugged_interfaces

-rw-r--r--. 1 root root   23 Apr 22 21:26 plugged_interfaces.sorted

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf octavia]# cd 3c22219d-7c34-48f3-acf6-6e15f76ec9a1

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf 3c22219d-7c34-48f3-acf6-6e15f76ec9a1]# ls

3c22219d-7c34-48f3-acf6-6e15f76ec9a1.pid  haproxy.cfg

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf 3c22219d-7c34-48f3-acf6-6e15f76ec9a1]#

 

8. haproxy.cfg 파일 내용을 확인해 보니 로드밸런서를 생성할때 지정해 주었던 인스턴스들의 IP가 보이고, 로드밸런서 VIP도 확인할 수 있습니다.

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf 3c22219d-7c34-48f3-acf6-6e15f76ec9a1]# cat haproxy.cfg

# Configuration for cmp-was-lb

global

    daemon

    user nobody

    log /dev/log local0

    log /dev/log local1 notice

    stats socket /var/lib/octavia/3c22219d-7c34-48f3-acf6-6e15f76ec9a1.sock mode 0666 level user

    maxconn 1000000

 

defaults

    log global

    retries 3

    option redispatch

    timeout connect 5000

    timeout client 50000

    timeout server 50000

 

frontend 3c22219d-7c34-48f3-acf6-6e15f76ec9a1

    option tcplog

    maxconn 1000000

    bind 10.10.10.13:80

    mode tcp

    default_backend 42e1058e-a298-42b3-83ce-1123c2d94547

 

backend 42e1058e-a298-42b3-83ce-1123c2d94547

    mode tcp

    balance roundrobin

    stick-table type ip size 10k

    stick on src

    timeout check 5s

    fullconn 1000000

    server 8d712f3b-1ee1-47ef-8c0a-4779fd044365 10.10.10.8:80 weight 1 check inter 5s fall 10 rise 10

    server a523158c-cddb-4528-b5bd-660971ff08a1 10.10.10.9:80 weight 1 check inter 5s fall 10 rise 10

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf 3c22219d-7c34-48f3-acf6-6e15f76ec9a1]# exit

[heat-admin@con1 ~]$ 

 

이제 아래 그림이 이해가 가시나요? 왜 이런 그림이 나왔는지, 어떻게 동작하는지도 조금은 이해를 하셨으리라 생각이 듭니다.

 

 

이렇게해서, 2019년도 두번째 포스팅을 마무리해 봅니다. 모두들!!! 즐거운 주말되세요~~~

Posted by 나리 짱!!! naleejang
OpenStack2019.05.06 20:19

안녕하세요!! 

 

그동안 어떻게 지내셨나요? 저는 그동안 여러 프로젝트를 하느라 정말 바쁜 나날을 보내고 있었습니다. 그래서, 블로그에 글을 올릴 시간조차 없었네요! 오늘도 사실은 영어로 포스팅을 하려고 하다가 시간도 너무 오래 걸리고, 영어로 바로 쓰려니 무슨말을 어떻게 써야할지 생각조차 나질 않더라구요! 그래서, 그냥 2019년에 처음으로 쓰는 블로그 글이니까 그냥 한글로 오랜만에 써보기로 했어요. 그리고나서, 다시 영어로 바꿔 쓰면 되니까요!!

 

오늘은 Octavia에 대해서 한번 써보려고 해요. 오픈스택이 뭘하는건지는 다들 아실테고, 오픈스택이 어떤 서비스로 이루어져 있는지도 다들 아실꺼라 생각이 듭니다. 아래 그림이 레드햇에서 제공하는 오픈스택 아키텍처입니다. 요즘 오픈스택에는 너무나도 많은 서비스들이 있기 때문에, 그 중에서도 가장 많이 사용하는 서비스들을 아래와 같이 레드햇에서 제공을 하고 있습니다. 

 

그럼, 오늘 이야기할 Octavia가 뭐냐구요? 뭐냐하면, 바로 Load Balancer 서비스입니다. 로드밸런서가 뭐냐구요? 로드밸런서는 한마디로 말해서 많은 사용자가 웹사이트를 사용할때 웹사이트의 부하를 분산해주는 부하 분산 처리기라고 할 수 있습니다. 종류도 L3(IP기반), L4(IP+Port 기반), L7(사용자 어플리케이션 기반) 으로 여러가지입니다.

 

아래 그림은 오픈스택의 Octavia라는 로드밸런서의 아키텍처입니다.

쉽게 이야기하면 사용자는 웹사이트를 접속하기 위해 Amphora라는 인스턴스에서 실행되는 https 또는 http 리스너를 통해 웹사이트에 접속을 합니다. 이때 접속할 웹사이트들의 집합을 Pool이라고 하고 웹사이트들을 Pool의 Member라고 합니다. 그리고, Member들이 잘 살아있는지, 정상적으로 동작을 하는지를 체크하는 모니터링 도구를 Pool Health Monitor라고 합니다.   

 

이렇게 Octavia에서 제공하는 로드밸런서는 아래와 같은 서비스들로 구성되어 있습니다.

- 로드밸런서

- Amphora 인스턴스

- 리스너(Listener)

- 풀(Pool)

- 멤버(Member)

- 헬스체크 모니터(Health-check Monitor)

 

여기서 가장 중요한 역할을 하는건 바로 amphora 라고 불리는 인스턴스입니다. amphora 인스턴스는 Red Hat Enterprise Linux 7.6 기반에 Haproxy 데몬이 설치되어 있습니다. 그리고, Octavia-agent가 Octavia-server로부터 명령을 받아 Listener를 생성하고 Haproxy에 환경설정을 하고 VIP를 Virtual Network로 생성을 하는 역할을 합니다. 그러면, 클라이언트는 Octavia-agent에 의해 생성된 VIP를 통해 Haproxy가 연결해주는 VM으로 접근을 하게 되는 것입니다. 

 

 

그럼, 이제 데쉬보드를 통해 로드밸런서를 한번 만들어 볼까요? 

레드햇 오픈스택 13 버전의 데쉬보드에서는 Project > Network > Load Balancers 메뉴를 통해 로드밸런서를 만들수 있습니다. 아래와 같이 메뉴를 찾아 들어가면 로드밸런서 목록을 확인할 수 있습니다. 그러나 생성된 로드밸런서가 없으니 아무것도 없겠죠! 

 

상단의 [+Create Load Balancer] 버튼을 클릭하면 아래와 같이 Load Balancer 화면이 뜹니다. 그러면, 아래와 같이 Name을 입력합니다. 이때 고정IP를 사용하고 싶다면 IP address에 사용하고자 하는 IP를 입력합니다. 그리고, 해당 IP가 포함된 서브넷을 선택합니다. 입력하지 않는다면 DHCP에 의한 IP가 할당됩니다.

- Name : 로드밸런서 이름

- Description : 로드밸런서 설명

- IP address : 로드밸런서로 사용할 VIP 주소

- Subnet: VIP가 포함된 네트워크 서브넷

 

이번에는 리스너를 만들어보겠습니다. 아래와 같이 리스너 Name, Protocol, Port를 입력합니다.

- Name: 리스너 이름

- Description: 리스너 설명

- Protocol: 프로토콜로 HTTP, TCP, UDP를 선택할 수 있음.

- Port: 리스닝을 할 포트

- Connection Limit: 접속 제한, -1은 제한을 하지 않겠다는 의미임

 

리스너 정보 입력이 끝나면 풀에 대한 정보를 입력합니다.

- Name: 풀 이름

- Description: 풀 설명

- Session Persistence: 세션 지속 방법

- Algorithm: 로드밸런서 방법

 

풀에 대한 정보 입력후 이번에는 멤버를 선택합니다. 앞에서 이미 서브넷을 선택했습니다. 따라서 해당 서브넷에 이미 생성된 인스턴스 목록을 Available Instances 에서 확인할 수 있습니다. 그럼, 로드밸런싱을 할 인스턴스를 2개 이상 선택합니다. 여기서는 앞에서 HTTP를 선택했기 때문에 자동으로 80 port가 설정되지만, 만일 TCP나 UDP를 선택했다면 해당 Port를 입력해야 합니다.

 

마지막으로 모니터링에 대한 정보를 입력합니다. 여기서는 모니터링 타입을 Ping으로 선택했습니다. 그리고, 하단의 [Create Load Balancer] 버튼을 클릭합니다.

 

그러면 로드밸런서 목록에서 아래와 같이 로드밸런서가 생성되고 있는것을 확인할 수 있습니다.

 

로드밸런서 생성이 완료되면 아래와같이 Provisioning Status가 Pending Create 에서 Active로 변경됩니다.

 

생성이 완료된 로드밸런서에 외부에서 접속이 가능할 수 있도록 Floating IP를 설정해 보도록 하겠습니다. Floating IP를 할당할 로드밸런서 우측 버튼을 클릭하여 [Associate Floating IP] 버튼을 클릭하고 아래와 같이 External IP나 서브넷을 선택하고 하단의 [Associate] 버튼을 클릭합니다.

 

할당된 IP는 로드밸런서 상세정보에서 아래와 같이 확인할 수 있습니다.

 

상세정보에서 Listeners 탭을 클릭하면 아래와 같이 리스너 목록을 확인할 수 있습니다.

 

리스너 목록에서 리스너를 클릭하면 아래와 같이 리스너 정보와 풀 목록을 확인할 수 있습니다.

 

풀 목록에서 풀을 클릭하면 해당 풀의 상세정보와 함께 Health Monitors와 Members 목록을 확인 할 수 있습니다.

 

생성된 로드밸런서용 amphora 인스턴스는 관리자 계정으로 들어가서 Admin > Compute > Instances 메뉴에서 아래와 같이 확인할 수 있습니다.

 

 

이제 로드밸런싱이 제대로 되는지 테스트를 해보도록 하겠습니다. 컨트롤러 노드에서 ip netns를 명령어를 이용하며 가상 네트워크 및 라우터 정보를 확인할 수 있습니다. 테넌트 네트워크가 포함된 라우터 정보를 ip netns exec 명령어를 이용하여 해당 테넌트의 VIP에 curl를 실행하면 아래와 같이 로드밸런싱이 되는 것을 확인할 수 있습니다. 또한 연결해 준 Floating IP로 curl를 실행하면 역시 로드밸런싱이 되는것을 확인 할 수 있습니다.

[root@overcloud-controller-0 ~]# ip netns exec qrouter-355b554a-a5a2-4ff5-878f-1fb3f0de6509 curl http://10.10.10.13 

Welcome to 10.10.10.9

[root@overcloud-controller-0 ~]# ip netns exec qrouter-355b554a-a5a2-4ff5-878f-1fb3f0de6509 curl http://10.10.10.13

Welcome to 10.10.10.8

[root@overcloud-controller-0 ~]# curl http://192.168.122.56

Welcome to 10.10.10.9

[root@overcloud-controller-0 ~]# curl http://192.168.122.56

Welcome to 10.10.10.8

[root@overcloud-controller-0 ~]#

 

 

이렇게 해서 오픈스택의 로드밸런서 서비스인 Octavia에 대해서 알아보았습니다. 다음에는 Octavia 인스턴스에 접속을 해서 Octavia가 어떻게 구성이 되었는지 확인해 보도록 하겠습니다. 

Posted by 나리 짱!!! naleejang
Life2018.12.26 23:13

Hello my friends that visit my blog. 


How was your Christmas holiday? In my case, I enjoyed that day with my daughter and husband. We had delicious food and watched movie "Aqua Man" in 4D theater. And we took some picture with Christmas tree. This Christmas was really wonderful day.


Today, I thought that I want to look back my life of this year and to post about this year's my story in English for my foreign friends. Because I want what my English writing skill upgrade. 


In this year, I was a lot of work. Dream that I wanted in this year was accomplished great. 

I wanted to post my story about work and technical in English at this blog. so I started to write episode about my Ansible training. First my posting was not good. I didn't knew how to express in English well. So my English sentence was not good. However, I was my best. I think this express still is not good. But If I try and try to express in English, I believe my English skill will improved.  


Below articles are my English postings.



After writing my Ansible training episodes, I had a opportunity about presenting my ansible story with openstack at Open Infra Days Korea 2018 event.


For I prepare presentation slides, I made test environment in my notebook computer. I installed KVM hypervisor in my rhel notebook. And, I created vm for installing Ansible tower. After installing Ansible tower, I developed playbooks for installing gitlab. I uploaded my playbook sources to gitlab that installed by ansible tower. So I completed Ansible environment for test.


And then I made small Openstack environment on KVM. It was small controller node 1ea, small compute node 1ea. 


When many people built Openstack, they did Openstack function test a lot. It is iterative work. So I developed playbook for iterative work and I executed job templates a lot for presentation demo.


And I made presentation slides. My presentation of Open Infra Days Korea 2018 event was so nice. Many people attended to my sessions. Of course, the language was Korean. But I wanted to share my presentation episode to my friends. So I changed my presentation's language from Korean to English. And I posted it to my blog. Below is the posting.



As soon as finish the event, I went to Gwangju for working Openstack NFV project. And I worked hard for 5 months. I really learned a lot of things through the project. 




Um... at the September, I attended at Red Hat Tech Exchange 2018 APAC as a speaker. While I prepare the presentation, I had to work a lot. Also I had to made presentation slide and I had to practice presentation in English. It was presentation review day. At the day, I was forgetting this. Because I was training about openstack to my client. APEC manager was angry a lot because me. Anyway I made a plan for presentation reviw with apec manager and my manager. My presentation review was a successful.


How was real my presentation?

Of course, It was a successful. Many people attended my session. So many people sent cheering and clapping to me. I was so happy. 




Looking back on 2018, I want to thank to my supporters. So I prepared small gifts. I started to give the gift with a letter.



I have new plans of new year. I want to improve my technical skill, English skill and communication skill. And I want to share my experience about technical to many people in the world.

'Life' 카테고리의 다른 글

Looking back on 2018~!!  (0) 2018.12.26
Red Hat! and After 1 year  (0) 2018.04.30
[후기] OpenStack Boston Summit 2017  (3) 2017.05.14
[Life] New Start for Dream! and Work! with RedHat  (1) 2017.03.08
OpenStack Austin Summit 2016을 다녀와서  (2) 2016.05.05
Start-up에서 일한다는 건  (0) 2016.03.04
Posted by 나리 짱!!! naleejang