Browsing Tag

Naver Cloud PlatForm

NCP

[NCP] 삶의 질을 높여주는 Image Optimizer를 이용한 이미지 리사이징

안녕하세요. ManVSCloud 김수현입니다.

오늘은 Image Optimizer에 대한 포스팅을 해보았습니다.
Image Optimizer에 대한 글은 이미 네이버 클라우드 플랫폼에서도 많은 글과 영상으로 만들어두어 접근하기 쉬운 상태입니다.

제가 직접 Image Optimizer를 사용해본 소감에 대해 써보았으니 사용 전에 어떻게 사용하면 좋을지 참고하실 때 도움되리라 생각됩니다.


왜 Naver Cloud Platform의 IMAGE OPTIMIZER인가?

  • 쉬운 사용법
    (크기, 워터마크, 필터 등 UI를 통해 원하는 효과를 체크하고 수치만 입력하면 됩니다.)
    ([예시 보기]가 있어 예시를 통해 쉽게 사용할 수 있습니다.)
  • 미리 보기 제공
    (미리 보기를 제공하여 조금 더 간편함을 느낄 수 있었습니다.)
  • 콘솔에서 효과 추가
    (콘솔에서 원하는 효과만 선택하여 넣는 방식입니다.)

타 클라우드를 이용한 이미지 리사이징 경험

우선 이미지 리사이징에 대한 경험은 크게 네이버 클라우드 플랫폼과 AWS 에서 사용해보았습니다. AWS에서는 이미지 자동 리사이징을 진행해보았으며 Azure 역시 Azure Event Grid를 이용하여 이미지 리사이징이 가능한 것을 금방 찾을 수 있었습니다.

개발자가 아닌 입장에서 코드 개발 부분이 정말 막막했었습니다.

물론 이미지 자동 리사이징을 이용하여 이미지 사이즈가 고정적이지 않을 경우 개발적인 부분이 사용될 수 밖에 없겠지만 이미지 사이즈가 고정적으로 정해져있는 상태에서 빠르게 추가하는 방식으로 사용할 수는 없을까라는 생각을 하게되었습니다.

네이버 클라우드에서 Image Optimizer 서비스를 이용하면 가능합니다.
물론 자동 리사이징의 경우 동일하게 개발적인 요소가 사용되겠지만 Image Optimizer를 이용한다면 고정적인 사이즈에 대해서 리사이징은 충분히 쉽게 가능하겠다라고 생각했습니다.


Image Optimizer를 이용한 이미지 리사이징

🏆 Object Storage

우선 Object Storage를 생성해주어야합니다.
Object Storage에 이미지를 업로드 하고 Image Optimizer를 이용하여 해당 이미지에 여러 효과를 줘보도록 하겠습니다.

버킷 이름은 고유합니다.
원하시는 고유한 버킷 이름을 정해주도록 합시다.
파일에 대한 공개 여부를 설정하는 곳입니다.
생성한 Bucket에 이미지를 리사이징 할 이미지를 업로드 해줍시다.

image 라는 폴더를 하나 생성한 후 image 폴더 안에 이미지를 업로드 했고
해당 폴더를 공개하여 외부에서 접근할 수 있도록 해주었습니다.


🎨 Image Optimizer

이제 Image Optimizer를 생성해줄 차례입니다.

Image Optimizer 프로젝트를 생성해주고 프로젝트 이름을 입력한 뒤
원본 이미지 저장소는 위에서 만들어준 Object Storage를 선택해줍시다.

서비스 프로토콜과 서비스 도메인을 정해주어야합니다.

“고객 보유 도메인”을 선택할 경우 당연히 DNS와 연결도 해주어야합니다.
그리고 HTTP로 하니까 계속 오류가 발생해서 HTTPS로 설정해주었습니다.
HTTP로 설정하니까 CDN 도메인 접속 시 이미지를 정상적으로 불러오지 못해서 이런저런 테스트를 해봤는데 HTTPS에서만 정상 접근이 가능하다는 걸 알게됐습니다.
(음?.. HTTP는 왜 있는거지..? 내가 설정을 잘못한 부분이 있는건가..?)

위 이미지 처럼 다음 및 생성을 해주고 최종 설정은 다음과 같이 설정했습니다.
HTTP에서 이미지를 정상적으로 못불러와서 ALL로 설정하고 HTTPS에서 정상 이미지 출력이 확인되었습니다.

자, 그럼 이제 쿼리스트링을 만들어 봅시다.

크기, 워터마크, 필터 별로 원하는 쿼리스트링을 만들 수 있습니다.
리사이즈를 해주고 가로,세로 길이 변경 및 품질을 변경해줬으며 흑백으로 출력되도록 해줬습니다.
이게 참 마음에 들었던 게 이대로 클릭하고 수치만 입력했는데 쿼리스트링이 자동으로 만들어져서 자동 입력된다는게 좋았습니다.
쿼리스트링 입력 후 생성된 부분에 대해 변환 이미지 미리보기를 실행할 수 있습니다.
미리보기 결과입니다. 멋지지않나요?

미리 보기와 같이 이미지가 실제로 잘 반영되었을지 URL로 접속하여 결과를 보도록하겠습니다.


Result

제가 원하는대로 이미지가 잘 변환되었습니다.
잘 출력됐네요.

하지만 Image Optimizer에 등록되지 않은 쿼리스트링을 사용할 경우 404 Error가 발생하게됩니다.

쿼리스트링을 수동으로 입력하지 않고 자동으로 이미지를 변환하기 위해서는 Cloud Functions을 사용해야할 것으로 보입니다.


Personal Comments

Image Optimizer에 대한 포스팅을 8월부터 준비중이었으나 8월 말에 네이버 클라우드 플랫폼 공식 블로그에서 Image Optimizer에 대한 포스팅이 먼저 올라왔습니다.

아래 포스팅에서 이미 기능적인 설명이 다 적혀져있어서 오늘 포스팅은 기능적인 부분은 제외하고 AWS에서 이렇게 사용해봤는데 이런 경우엔 네이버 클라우드의 Image Optimizer가 좋은 것같다라는 경험을 이야기 해보고싶었습니다.

아래 네이버 클라우드 플랫폼 공식 블로그에 포스팅된 Image Optimizer에 대한 글도 참고하면 훨씬 사용에 도움될 것입니다.


NCP

[NCP] AWS to NCloud Server Migration – #2편

안녕하세요. ManVSCloud 김수현입니다.

오늘 “AWS TO NCLOUD SERVER MIGRATION – #2편”에서는 간단한 Install과 제가 기본적으로 설정하는 설정값들을 보여드리며 정보를 공유하고자 합니다.


Base Install

[root@manvscloud-web-pub-kr1 ~]# cat /etc/redhat-release
CentOS Linux release 7.8.2003 (Core)

“[NCP] AWS TO NCLOUD SERVER MIGRATION – #1편”에서 생성한 서버에 기본 설치와 설정 작업을 진행하기로 했습니다.

🧩 Nginx 설치
vi /etc/yum.repos.d/Nginx.repo
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/7/$basearch/
gpgcheck=0
enabled=1
[root@manvscloud-web-pub-kr1 ~]# yum install nginx -y

CentOS 7에서는 위와 같이 repo를 추가 후 설치를 진행하면 설치간에 큰 어려움은 없을 것입니다.

이후 LB를 붙이면 Nginx Access Log에서 LB의 로그로 나오기때문에 Client IP를 보기 위해서는 nginx -V 2>&1 | grep ‘http_realip_module’ 로 확인하여 http_realip_module이 있는지 확인이 되어야합니다.

RPM 설치 시 이 모듈이 들어가있는데 컴파일로 설치를 진행할 경우 이 부분을 잘 체크해주셔야합니다.

[root@manvscloud-web-pub-kr1 ~]# nginx -V 2>&1 | grep 'http_realip_module'
configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/run/nginx.pid --lock-path=/run/lock/subsys/nginx --user=nginx --group=nginx --with-compat --with-debug --with-file-aio --with-google_perftools_module --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_degradation_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_mp4_module --with-http_perl_module=dynamic --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-http_xslt_module=dynamic --with-mail=dynamic --with-mail_ssl_module --with-pcre --with-pcre-jit --with-stream=dynamic --with-stream_ssl_module --with-stream_ssl_preread_module --with-threads --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic' --with-ld-opt='-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,-E'
🔮 PHP 설치
[root@manvscloud-web-pub-kr1 src]# yum -y install http://rpms.remirepo.net/enterprise/remi-release-7.rpm
[root@manvscloud-web-pub-kr1 src]# yum -y install epel-release yum-utils
[root@manvscloud-web-pub-kr1 src]# yum-config-manager --disable remi-php54
[root@manvscloud-web-pub-kr1 src]# yum-config-manager --enable remi-php74
[root@manvscloud-web-pub-kr1 src]# yum install -y php php-json php-cli php-gd php-pear php-common php-mysqlnd php-fpm php-mbstring php-opcache php-process php-xmlrpc php-pdo php-xml php-bcmath php-devel php-zip php-mcrypt
[root@manvscloud-web-pub-kr1 src]# yum groupinstall " Development Tools" -y
[root@manvscloud-web-pub-kr1 src]# yum install ImageMagick ImageMagick-devel -y
[root@manvscloud-web-pub-kr1 src]# pecl install imagick
[root@manvscloud-web-pub-kr1 src]# echo "extension=imagick.so" >> /etc/php.ini
[root@manvscloud-web-pub-kr1 src]# systemctl enable php-fpm
[root@manvscloud-web-pub-kr1 src]# systemctl start php-fpm

PHP는 remi를 이용하여 설치를 진행했습니다.
Migration할 때 주의할 점 중 하나는 PHP의 모듈을 맞춰주는 것입니다.
기존 서버와 이전하는 서버에서 php -m 로 확인해줍시다.

🧿 MariaDB 설치
vi /etc/yum.repos.d/MariaDB.repo
[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.5/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1
yum install MariaDB-server MariaDB-client -y

MariaDB도 repo만 추가해주면 쉽게 설치할 수 있습니다.
MariaDB의 버전은 baseurl 부분에서 10.5 부분을 원하시는 버전으로 변경하면 원하시는 버전으로 설치가 가능합니다.

🎫 Memcached

Memcached의 경우 개인 사이트 운영에 큰 효과를 가져다주지 못한다는 평이 있었으나 개인 블로그 용도뿐만 아니라 다양한 테스트를 해볼 예정이기에 memcached를 도입하기로 했습니다.

[root@manvscloud-web-pub-kr1 ~]# yum clean all
[root@manvscloud-web-pub-kr1 ~]# yum update -y
[root@manvscloud-web-pub-kr1 ~]# yum install memcached -y
[root@manvscloud-web-pub-kr1 ~]# cat /etc/sysconfig/memcached 
PORT="11211"
USER="memcached"
MAXCONN="1024"
CACHESIZE="64"
OPTIONS=""

/etc/sysconfig/memcached 값을 아래와 같이 변경해주었습니다.

[root@manvscloud-web-pub-kr1 ~]# cp -avp /etc/sysconfig/memcached /etc/sysconfig/memcached_org
[root@manvscloud-web-pub-kr1 ~]# vi /etc/sysconfig/memcached
PORT="11111"
USER="memcached"
MAXCONN="2048"
CACHESIZE="4096"
OPTIONS=""

[root@manvscloud-web-pub-kr1 ~]# systemctl enable memcached
[root@manvscloud-web-pub-kr1 ~]# systemctl start memcached

php-memcached도 설치해줍시다!

[root@manvscloud-web-pub-kr1 ~]# yum install php-memcached -y

php.ini를 보면 session.save_handler가 files로 되어있습니다.

이를 memcached로 변경해줄 것입니다.
아래처럼 작업을 진행할 수 있습니다.

[root@manvscloud-web-pub-kr1 ~]# cp -avp /etc/php.ini /etc/php.ini_org
[root@manvscloud-web-pub-kr1 ~]# cat -n /etc/php.ini | grep -E "session.save_handler|session.save_path"
  1214	session.save_handler = files
  1222	;     session.save_path = "N;/path"
  1238	;     session.save_path = "N;MODE;/path"
  1247	;session.save_path = "/tmp"
  1332	;       (see session.save_path above), then garbage collection does *not*
[root@manvscloud-web-pub-kr1 ~]# sed -i '1214s/files/memcached/g' /etc/php.ini
[root@manvscloud-web-pub-kr1 ~]# perl -p -i -e '$.==1222 and print "session.save_path = \"127.0.0.1:11111\"\n"' /etc/php.ini
[root@manvscloud-web-pub-kr1 ~]# cat -n /etc/php.ini | grep -E "session.save_handler|session.save_path "
  1214	session.save_handler = memcached
  1222	session.save_path = "127.0.0.1:11111"
  1223	;     session.save_path = "N;/path"
  1239	;     session.save_path = "N;MODE;/path"
  1248	;session.save_path = "/tmp"
  1333	;       (see session.save_path above), then garbage collection does *not*
[root@manvscloud-web-pub-kr1 ~]# systemctl restart memcached
[root@manvscloud-web-pub-kr1 ~]# systemctl restart php-fpm

그냥 블로그만 운영하던 서버다보니 크게 설치할 것들이 별로 없습니다.
이제 기본 세팅만 진행해보도록 합시다.


Default Settings

우선 sshd 설정을 먼저 진행하기로 했습니다.
설정 조건은 아래와 같습니다.

  • SSH 포트를 22에서 15222로 변경할 것
  • manvscloud 사용자 생성 및 sudo로 root권한 사용
  • root로 바로 접속할 수 없도록 설정
  • 접속 시 Password가 아닌 Public Key 파일을 이용하여 로그인
[root@manvscloud-web-pub-kr1 ~]# useradd manvscloud
// 먼저 서버에 key 파일을 업로드 한 뒤 작업을 진행하였습니다.

[root@manvscloud-web-pub-kr1 ~]# chmod 400 manvscloud.pem
[root@manvscloud-web-pub-kr1 ~]# mkdir /home/manvscloud/.ssh
[root@manvscloud-web-pub-kr1 ~]# ssh-keygen -y -f manvscloud.pem > /home/manvscloud/.ssh/authorized_keys
[root@manvscloud-web-pub-kr1 ~]# chown -R manvscloud:manvscloud /home/manvscloud/.ssh
[root@manvscloud-web-pub-kr1 ~]# chmod 700 /home/manvscloud/.ssh
[root@manvscloud-web-pub-kr1 ~]# chmod 600 /home/manvscloud/.ssh/authorized_keys

[root@manvscloud-web-pub-kr1 ~]# id manvscloud
uid=1001(manvscloud) gid=1001(manvscloud) groups=1001(manvscloud)
[root@manvscloud-web-pub-kr1 ~]# gpasswd -a manvscloud wheel
Adding user manvscloud to group wheel
[root@manvscloud-web-pub-kr1 ~]# gpasswd -a manvscloud systemd-journal
Adding user manvscloud to group systemd-journal

[root@manvscloud-web-pub-kr1 ~]# grep -E "wheel|systemd-journal" /etc/group
wheel:x:10:manvscloud
systemd-journal:x:190:manvscloud

[root@manvscloud-web-pub-kr1 ~]# cat << EOF > /etc/sudoers.d/10-manvscloud-users
> # User rules for manvscloud
> manvscloud ALL=(ALL) NOPASSWD:ALL
> EOF
[root@manvscloud-web-pub-kr1 ~]# chmod 440 /etc/sudoers.d/10-manvscloud-users
[root@manvscloud-web-pub-kr1 ~]# passwd -l root
Locking password for user root.
passwd: Success

///etc/ssh/sshd_config 파일 수정

[root@manvscloud-web-pub-kr1 ~]# cat -n /etc/ssh/sshd_config  | grep -E "Port|PermitRootLogin|PasswordAuthentication"
    17	#Port 22
    38	PermitRootLogin yes
    63	#PasswordAuthentication yes
    65	PasswordAuthentication yes
    88	# PasswordAuthentication.  Depending on your PAM configuration,
    90	# the setting of "PermitRootLogin without-password".
    92	# PAM authentication, then enable this but set PasswordAuthentication
   100	#GatewayPorts no


[root@manvscloud-web-pub-kr1 ~]# cp -avp /etc/ssh/sshd_config /etc/ssh/sshd_config_org
[root@manvscloud-web-pub-kr1 ~]# sed -i '38s/yes/no/g' /etc/ssh/sshd_config
[root@manvscloud-web-pub-kr1 ~]# sed -i '65s/yes/no/g' /etc/ssh/sshd_config
[root@manvscloud-web-pub-kr1 ~]# perl -p -i -e '$.==17 and print " Port 15222\n"' /etc/ssh/sshd_config

[root@manvscloud-web-pub-kr1 ~]# systemctl restart sshd

다음은 php설정을 해줄 것입니다.

우선 php.ini 파일과 www.conf 파일을 수정할건데 pm 값을 조정하는 최적화 작업은 기본 설정에서 제외하였습니다.

php.ini파일에서는 아래와 같이 값을 변경해주었습니다.

   date.timezone = "Asia/Seoul"
   expose_php = Off
   short_open_tag = On
   allow_url_fopen = Off
   max_execution_time = 60
   memory_limit = 128M

이번 이전에서 포인트로 정한 php-fpm의 파일 소켓 통신을 설정하는 부분입니다.
www.conf에서 기존 listen이 127.0.0.1:9000로 TCP/IP 소켓 통신이 기본값인데 이를 /run/php-fpm/www.sock 으로 변경하여 Unix Socket 통신이 되도록 하였습니다.

[root@manvscloud-web-pub-kr1 ~]# cat -n /etc/php-fpm.d/www.conf | grep listen | grep -v ";"
    38	listen = 127.0.0.1:9000
    64	listen.allowed_clients = 127.0.0.1
[root@manvscloud-web-pub-kr1 ~]# sed -i '38s$127.0.0.1:9000$/run/php-fpm/www.sock$g' /etc/php-fpm.d/www.conf
[root@manvscloud-web-pub-kr1 ~]# cat -n /etc/php-fpm.d/www.conf | grep listen | grep -v ";"
    38	listen = /run/php-fpm/www.sock
    64	listen.allowed_clients = 127.0.0.1

이 Unix Socket 방식은 TCP의 소켓과 동일하게 API로 데이터를 주고받을 수 있는데 이는 로컬 파일 기반 소켓이라서 Nginx와 함께 쓰기 위해 php-fpm를 같은 로컬내에 존재하도록 하였습니다. 이 방식은 localhost 내에 프로세스 간 통신이라 속도도 우월하고 메모리 소모를 줄일 수 있습니다.

📄 nofile 설정
vi /etc/security/limits.conf
*               soft    nofile          65535
*               hard    nofile          65535

위 설정을 해주지 않으면 파일 열기 최대 개수가 soft/1024, hard/4096이 default인 것으로 기억합니다.

💿 History
[root@manvscloud-web-pub-kr1 ~]# cat -n /etc/profile | grep HISTFILESIZE
    78	HISTFILESIZE=0
[root@manvscloud-web-pub-kr1 ~]# sed -i '78s/0/5000/g' /etc/profile
[root@manvscloud-web-pub-kr1 ~]# cat -n /etc/profile | grep HISTFILESIZE
    78	HISTFILESIZE=5000
[root@manvscloud-web-pub-kr1 ~]# echo export HISTTIMEFORMAT=\"[%F %T] \" > /etc/profile.d/bash_history.sh
[root@manvscloud-web-pub-kr1 ~]# chmod 755 /etc/profile.d/bash_history.sh
[root@manvscloud-web-pub-kr1 ~]# init 6

저는 history를 자주 이용하는 편입니다.
그런데 기본 설정을 하고 다음 날 서버에 접속했는데 history가 하나도 남아있지 않아 확인해보니 HISTFILESIZE가 0으로 되어있어 이를 변경해주기로 하였습니다.

값을 5000으로 변경해주고 HISTTIMEFORMAT을 주어 history에 시간대도 확인할 수 있도록 설정해두었습니다.

Nginx와 MariaDB 설정은 다음 #3편에서 스토리지 추가 및 NAS 연결과 함께 설정을 진행할 것입니다.


Personal Comments

#3편에서는 “ManVSCloud 신규 Architecture” 공개와 함께 스토리지 추가 및 NAS 연결에 대한 포스팅을 진행할 것입니다.

제가 이번에 진행하는 AWS to NCloud 이전 작업에서 설정되는 부분이나 이렇게 이전이 될 수도 있구나하는 걸 재밌게 봐주셨으면 합니다.

긴 글 읽어주셔서 감사합니다.


NCP

[NCP] AWS to NCloud Server Migration – #1편

안녕하세요. ManVSCloud 김수현입니다.

이미지 출처 : https://www.mk.co.kr/news/it/view/2021/08/819941/

네이버 클라우드의 빠른 성장이 지속되고 있습니다.
현재 국내 클라우드 기업중 네이버 클라우드가 독보적으로No.1이라 봅니다.

올해 7월 네이버 클라우드는 공공기관 시장에서 97.64%의 점유율의 성적을 보이며
왜 네이버 클라우드인지 증명해냈습니다.

제 manvscloud.com 블로그도 이제 AWS를 떠나 네이버 클라우드 플랫폼으로 이전하게 되었습니다.

현재 전체적인 환경을 파악하고 있으며 네이버 클라우드 플랫폼에서는 기존 AWS에서 사용하던 아키텍처와 다르게 사용하고 싶어 새로운 아키텍처를 구상하고 있습니다.

네이버 클라우드 플랫폼의 기술력과 발전 가능성을 고려해본다면 먼저 네이버 클라우드를 시작하고 싶다라는 생각이 듭니다.


AWS Env

우선 네이버 클라우드 플랫폼으로 이전하기 전에 기존 AWS 환경에서 구성되어있던 아키텍처와 인스턴스 내 각 서비스들의 버전들을 파악하기로 했습니다.

먼저 기존 아키텍처는 예전에 만들어둔 것으로 가져왔습니다.
조금 추가된 부분이 있다면 AWS 한국 리전에서는 SNS에서 SMS 기능을 선택할 수 없습니다. 그렇기 때문에 추가적인 Lambda 작업이 있었습니다…

(네이버 클라우드는 따로 추가적인 작업없이 간단하게 모니터링 설정에서 SMS 문자 알림을 받을 수 있도록 설정할 수 있기에 이런 고통에서 벗어날 수 있게 되었습니다…😂)

[root@ip-10-0-1-68 ~]# cat /etc/*-release
NAME="Amazon Linux"
VERSION="2"
ID="amzn"
ID_LIKE="centos rhel fedora"
VERSION_ID="2"
PRETTY_NAME="Amazon Linux 2"
ANSI_COLOR="0;33"
CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2"
HOME_URL="https://amazonlinux.com/"
Amazon Linux release 2 (Karoo)

Linux 버전은 Amazon Linux AMI 2 를 사용하고 있었습니다.
네이버 클라우드로 이전하게 되면 CentOS 7을 사용할 것입니다.
원래 Rocky Linux 8을 써보고 싶었지만 아직 Rocky Linux 소식이 없어 CentOS 7로 결정하게 되었습니다.

[root@ip-10-0-1-68 home]# apachectl -v
Server version: Apache/2.4.46 ()
Server built:   Aug 24 2020 18:54:20

[root@ip-10-0-1-68 home]# php -v
PHP 7.4.15 (cli) (built: Feb 11 2021 17:53:39) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.15, Copyright (c), by Zend Technologies

두번째로 제 블로그는 APM으로 구성되어 있는데 이번 기회에 Apache에서 Nginx로 변경을 결정했습니다. 또한 Nginx 와 php 간에 TCP Socket을 사용하지 않고 Unix Socket을 사용해볼 것입니다. 이는 제가 늘 보고 배우는 Linuxer 님의 Blog를 보고 저도 이를 적용해보기로 마음먹게 되었습니다.

마지막으로 DB입니다. 원래 아키텍처는 WEB과 DB가 나뉘어져 있었습니다.
단, 인스턴스 하나가 죽으면 서비스가 마비가 되어 이번에 네이버 클라우드로 이전하면 WEB과 DB를 하나의 서버로 쓰되 이중화를 구성하기로 했습니다.

최종적으로 아키텍처가 완성되면 추가 블로깅 및 설명해볼 것입니다.


Naver Cloud Platform, Resource Creation

🌏 VPC
manvscloud-vpc
subnet

VPC를 구성하는 부분은 이제 너무 쉬우니 이렇게 구성했습니다!만 보여주고 넘어가도록 하겠습니다.

💻Server
server creation

서버는 하나만 생성해두었습니다.

서버 하나에 기본적인 설치 및 구성을 끝내두고 이미지를 생성하여 생성한 이미지를 이용하여 이중화를 구성할 것입니다.

참고로 오늘은 “AWS TO NCLOUD SERVER MIGRATION”에 대한 전반적인 느낌만 잡아가는 포스팅이며 추가 포스팅에서 완성된 아키텍처와 함께 어떻게 설치가되고 이전을 어떤 방식으로 진행했는지도 함께 적어볼 것입니다.

💾 Object Storage + Global CDN

현재 고민 중인 부분은 cdn을 어떻게 해결할까에 대한 부분입니다.
기존 AWS S3에 생각보다 많은 데이터가 쌓이게 되었고 이를 Object Storage에 넘겨준 뒤 나중에 DB에서도 수정해줘야하는 부분이 있기도 하고 기존에 CDN을 사용하고 있는 방식이 WordPress의 AWS 플러그인이라 이 부분이 잘 될지 확신이 되지 않기에 CDN은 조금 테스트를 진행해본 뒤 결정하게 될 것같습니다.


Personal Comments

이전을 진행하며 조금이나마 이런 기능을 만들어주었으면 좋겠다고 생각되는 부분이 있어
오늘은 네이버 클라우드에 바라는 점이 있다면 몇가지를 써보도록 하겠습니다.

  • SSL 인증서
    : Certificate Manager라는 서비스가 있는데 이는 외부에서 구매한 인증서를 입력하고 추가하는 것이라 추가적인 절차가 필요합니다.
    AWS의 ACM과 같은 서비스가 어서 생겼으면 좋겠습니다.
    (이 기능이 AWS를 사용하는동안 생각보다 매우 편리했기에 네이버 클라우드에도 도입되길 바랍니다.)
  • WAF
    : 네이버 클라우드에서 WAF를 사용하려면 Security Monitoring 라는 서비스에서 [이용 문의]를 통해서 사용이 가능합니다. 아직 AWS WAF처럼 사용자 선택하고 Count/Block 하는 방식이 아닌 신청해서 사용하는 방식으로 보입니다. 물론 네이버 클라우드 플랫폼의 WAF는 주간/월간 보고서 등의 장점도 있지만 사용자 지정 방식의 WAF도 생기다면 부담스럽지 않게 사용해볼 수 있을 것같습니다.
  • 주기적인 이미지/스냅샷 관리
    : 이미지/스냅샷을 사용자가 직접 백업 일정을 지정하고 진행하는 기능이 아직 없습니다.
    물론 Cloud Functions을 이용하면 해서 이런 기능을 만들 수는 있겠지만 개발자가 아닐 경우 난감할 수 있겠다 생각됩니다.
    그렇기 때문에 네이버 클라우드에서는 Backup이라는 서비스를 제공합니다.
    네이버 클라우드에서 직접 고객의 데이터를 백업해주고 보관해주는 서비스인데 상당히 괜찮습니다. 이 서비스만 신청해두면 사실 고객 입장에서는 직접적인 백업 관리를 하지 않아도 되니 용량별 비용만 고려하면 되어 오히려 편할 수 있습니다.

네이버 클라우드 플랫폼은 늘 빠른 업데이트와 기능 추가를 하고 있어 이러한 사용자들의 의견만 있다면 위 기능들 역시 금방 생길 거라 봅니다.

긴 글 읽어주셔서 감사합니다.


NCP

[NCP] 네이버 클라우드 9월 교육 및 행사 일정 공유 – (2)

안녕하세요. ManVSCloud 김수현입니다.

네이버 클라우드 플랫폼(Naver Cloud Platform) 9월 교육 및 행사 일정이 추가되어 공유드립니다.

Professional 과정 공인 교육과 웨비나, Brown-bag이 추가되었는데 아래 내용을 참고하여 교육을 신청해보시기 바랍니다.


공인교육 – Professional

  • Naver Cloud Platform에서는 기술자격증이 존재합니다. 이 교육은 그 중에서도 Professional Level 수준의 교육입니다.
  • 기존에는 실기 시험이 존재하였으나 2021년도 6월 이후로 실기 시험은 폐지되고 필기로만 시험이 진행됩니다.
  • 유료 교육입니다.
  • 수료증이 발급됩니다.

기존에는 NCA → NCP → NCE 순서로 시험 응시가 가능했지만 2021년도 7월 22일부터는 이전 레벨의 기술자격증이 없이 상위 기술자격증 취득이 가능합니다.

해당 교육이 유료 교육으로 되어있어 비용 부담이 될 수 있습니다.
그렇기때문에 네이버 클라우드에서는 edwith 사이트에서 공인 교육을 무료로 들을 수 있도록 강의를 게재하고 있습니다.

저 역시 Professional 자격증을 준비하며 edwith 사이트를 참고했습니다.


Webinar

이번 웨비나는 AI기반 스마트 제조 기술과 사례, 클라우드 기반 MES 부터 생산성을 높여주는 협업툴이 메인 주제라 봅니다.

아무래도 평일 오전에 진행되다보니 업무 시간과 겹쳐 집중해서 듣기 어려운 점이 있습니다.
저는 대부분의 교육을 반차나 연차를 내서 듣는 편이라 주요 관심사 주제가 아닌 경우 웨비나는 잘 안듣게됩니다.

업무 중 웨비나를 듣는데에 큰 지장이 없으시거나 관심이 있는 내용이시라면 웨비나 신청 추천드립니다!

  • 10:00 ~ 10:20 제조 기업의 스마트한 디지털 비즈니스 혁신
  • 10:20 ~ 10:30 클라우드 기반 제조업 RPA 업무자동화 도입과 활용
  • 10:30 ~ 10:50 클라우드 기반 가공/철근 MES 혁신 사례
  • 10:50 ~ 11:10 “스마트워크”로 가능한 제조기업의 혁신 전략
  • 11:10 ~ 11:30 제조 고객 사례 1. AIoT 기반 Industrial SaaS 서비스
  • 11:30 ~ 11:50 제조 고객 사례 2. 패키징 인쇄 griGoMOM
  • 11:50 ~ 12:10 AI 기반 스마트 제조 기술과 사례
  • 12:10 ~ 12:30 제조 기업을 위한 고가용성의 하이브리드 클라우드 서비스

Brown-bag

  • Zoom을 이용하여 교육을 들을 수 있어 온라인 환경이라 언제 어디서나 참여가 가능합니다.
  • 식사 쿠폰이 지급됩니다.
  • 점심 시간을 활용한 짧은 교육이므로 다소 어려운 교육이 아닙니다.
    간단하게 점심을 먹으며 들을 수 있는 난이도로 가벼운 마음으로 신청하셔도 될 것입니다.

쿠버네티스(Kubernetes)는 k8s, Kube 라고도 불리며 컨테이너화된 애플리케이션을 자동으로 배포(scheduling), 운영(HA, Failover), 확장(Scaling) 해주는 오픈소스입니다.

지난 5년간 kubernetes 관심도가 다소 많이 늘었습니다.
도커와 쿠버네티스가 아직 무엇인지 잘 모르신다면 점심 시간을 이용하여 간단하게 배워봅시다.

  • 가상화 기술
  • 컨테이너 기술의 역사
  • 도커 개요 및 주요 컴포넌트
  • 도커 핵심 기능
  • 쿠버네티스 등장 배경
  • 쿠버네티스 동작 원리 
  • 간단한 데모를 통해 pod 띄어보기

도커와 쿠버네티스에 대한 기본적인 지식을 습득하고 싶으신 분들 누구나 참가하실 수 있습니다.


Personal Comments

개인적으로 스터디를 하거나 교육을 듣는 걸 좋아합니다.
최근에는 스터디를 운영하기 위해 자료를 만드는데 생각보다 쉽지 않은 것같습니다.

너무 쉽지도 않고 어렵지도 않게 목표로 하는 수준의 내용을 맞추려하다보니 많은 고민을 하게됩니다. 항상 자료를 준비하고 교육하시는 분들… 존경합니다.

이번 포스팅을 통해 원하시는 교육 많이 참가해보시고 도움되시길 바랍니다.

긴 글 읽어주셔서 감사합니다.


IT/Linux/Kubernetes

[AKOS] Amazon EKS Study 시작

안녕하세요. ManVSCloud 김수현입니다.

오늘부터 CloudNet@에서 진행하는 AKOS(AWS Kubernetes Online Study)가 시작되었습니다. 2020년도는 Linuxer님, 2021년도는 가시다(Gasida)님과 함께하고 있습니다.

Kubernetes 스터디도 함께 했고 현재는 AWS의 EKS를 공부하고 있으며
Naver Cloud Platform의 NKS는 아마 따로 공부하게 될 것같습니다.


AWS Kubernetes Online Study

이전에 했던 DKOS(Docker Kubernetes Online Study)에 이어 AKOS(AWS Kubernetes Online Study)는 이제 배웠던 Kubernetes 과정을 이해한 뒤 AWS에서의 Kubernetes를 배워보는 시간이었습니다.

클러스터 구축
파드 생성 및 확인
RDS DB 확인

개인적으로 저는 이미 클라우드 환경에서는 AWS보다 Naver Cloud Platform을 이용해 Kubernetes를 먼저 사용해보았기 때문에 NKS가 조금 더 편하게 느껴졌습니다.

사용하기 편하고 쉬운건 Naver Cloud Platform의 NKS고 활용할 수 있는 범위는 넓은데 난이도가 높은 건 AWS의 EKS라고 해야하나? 개인적으로 그렇게 느껴졌습니다.

네이버 클라우드 플랫폼에서는 기본적으로 서비스를 만들 때 사용자가 편하게 사용할 수 있도록 배려하는 부분이 많다보니 아직 기능적인 부분에서는 다소 추가되어야할 부분이 있으나 추가된 이후가 기대되기는 합니다.


Personal Comments

끊임없이 공부하는 습관은 엔지니어에게 정말 좋은 습관이라고 생각합니다.
물론 부하가 생기지 않도록 컨디션 조절도 중요하지만요…

스케줄을 너무 가득 채워서 많은 것을 흡수 하려고 하면 오히려 번아웃이 한 번 찾아와 다시 시작하기가 너무 힘들더라구요.

오늘도 공부하는 엔지니어 분들 수고가 많으십니다.
과하게 하지말고 꾸준히 합시다.

긴 글 읽어주셔서 감사합니다.

NCP

[NCP] 네이버 클라우드 9월 교육 및 행사 일정 공유 – (1)

안녕하세요. ManVSCloud 김수현입니다.

네이버 클라우드 플랫폼(Naver Cloud Platform) 9월 교육 및 행사 일정을 공유드리려고 합니다.

현재 게재된 일정은 총 3가지가 있는데 해당하는 조건에 맞춰서 교육 신청을 하시면 좋을 것같습니다.


Hands-on Lab

  • 첫번째로 Hands-on Lab 입니다.
    Hands-on Lab은 네이버 클라우드 플랫폼(Naver Cloud Platform) 에서 최근까지 월 2회씩 꾸준히 진행되고 있는 교육입니다.
  • 권장하는 대상자는 클라우드 환경 및 네이버 클라우드를 처음 접하시는 분에게 가장 처음으로 추천드립니다.
  • 무료 교육입니다.

저 역시 네이버 클라우드 플랫폼을 접할 때 Hands-on Lab 교육을 들은 경험이 있고
해당 교육이 많은 도움이 되었기에 커뮤니티나 주변에서
“네이버 클라우드 어떻게 시작하면 좋을까요?”라는 질문을 받으면 가장 먼저 Hands-on Lab으로 시작해보라고 추천하고 있습니다.

※ TIP : Hands-on Lab 교육이 끝나고 난 후에도 해당 주차의 일요일까지 실습 계정을 사용할 수 있어 기본적인 실습 경험을 쌓을 수 있습니다.


공인교육 – Associate

  • Naver Cloud Platform에서는 기술자격증이 존재합니다. 이 교육은 그 중에서도 Associate Level 수준의 교육이라고 볼 수 있습니다.
  • Hands-on Lab 교육 이후 Associate 자격증을 노려보실 계획이라면 추천드립니다.
  • 유료 교육입니다.
  • 수료증이 발급됩니다.

해당 교육이 유료 교육으로 되어있어 비용 부담이 될 수 있습니다.
그렇기때문에 네이버 클라우드에서는 edwith 사이트에서 공인 교육을 무료로 들을 수 있도록 강의를 게재하고 있습니다.

저도 Professional 자격증 공부를 할 때 edwith 사이트를 이용한 경험이 있습니다.


대규모 웹서비스 및 글로벌 인프라 구축

  • Intermediate Level로 최소 Hands-on Lab 교육 이후 진행하는 것을 권장드리며
    특정 주제에 대해 교육을 듣기 전 사전 기본 지식을 요구합니다.
  • 무료 교육입니다.
  • 관심있는 분야에 대한 교육이 진행된다면 바로 신청합시다. 완전 강추!
    네이버 클라우드에서는 이렇게 사용할 수 있구나! 라는 걸 배울 수 있으며 상당히 재밌습니다.

개인적으로 제가 좋아하는 교육입니다.
DevOps, Big Data, Media, Kubernetes, AI, Security, Mongo DB 등 다양한 주제로 시간이 되면 항상 신청하는 편이며 관심있는 주제로 교육을 하면 휴가를 써서라도 듣고 있는 교육입니다.
이론뿐만 아니라 실습까지 재밌게 경험할 수 있습니다.


Personal Comments

처음 교육/행사 일정을 보고 “이 교육을 내가 들어도 괜찮은 교육일까?” 망설일 때가 있었습니다. 혹시라도 저와 같은 고민을 하시는 분들이 있을까하여 제 경험을 바탕으로 교육/행사 일정과 함께 제 경험을 공유드리고자 합니다.

이후 추가적인 교육 소식이 있을 경우 추가 포스팅 예정이며 조금 더 많은 분들께서 네이버 클라우드에 쉽게 접하실 수 있는 길을 항상 고민토록 하겠습니다.

지금까지 네이버 클라우드 플랫폼 Support Master 김수현이었습니다.

긴 글 읽어주셔서 감사합니다.


NCP

[NCP] 안녕하세요. 네이버 클라우드 Support Master 입니다.

안녕하세요. ManVSCloud 김수현입니다.

오늘 네이버 클라우드 플랫폼(Naver Cloud Platform) 공식 블로그에서 9인의 Master 멤버가 공개되었습니다.

다소 부족한 점이 많으나 공식 테크 앰버서더, 즉 Master 멤버의 기회가 주어져 Support Master로서 여러분들에게 큰 도움을 드릴 수 있게되었습니다.


Support Master

Support Master로서 저는 많은 네이버 클라우드 사용자 또는 사용하시고자 하는 분들을 Supporting을 하고자 Support Master가 되었습니다.

클라우드를 배워보고자하는 학생분들이나 온프레미스 환경에서 서비스를 운영하시다가 클라우드 환경으로 서비스를 이전하고자 하는 분 등 다양한 유저들에게 제가 알고 있는 지식을 공유하여 조금 더 네이버 클라우드를 쉽게 접하고 원활한 서비스를 운영하실 수 있도록 하는 것이 저의 목적입니다.

우선 네이버 클라우드에 대한 주제로 정기적인 블로그 포스팅이 있을 것이며 추가적인 도움을 드릴 수 있을 만한 자료를 준비하고 있습니다.

이 부분은 제 블로그를 통해 추가 공지될 예정입니다.


Naver Cloud Platform

네이버 클라우드에 대해 궁금하신 부분이 있으실 경우 댓글 남겨주시면 답변 도와드리도록 하겠습니다.

또한 이런 기회를 얻을 수 있도록 클라우드에 처음 흥미를 주신 서태호(Network Master)님과 기술 성장에 늘 도움주신 Linuxer님에게 늘 감사드리며 Master 활동 준비 및 지원해주시는 네이버 클라우드 플랫폼(Naver Cloud Platform)에 감사의 인사 올립니다.


NCP

[NCP] 네이버 클라우드에서 2TB 이상 파티션 사용하기 – Windows편

안녕하세요. ManVSCloud 김수현입니다.

오늘은 네이버 클라우드에서 Server 사용 시 Windows 환경에서 2TB 이상 파티션을 사용하는 방법에 대해 알아보도록 하겠습니다.


Environment and Description

📢 사용된 OS : win-2016-64-en

Linux 편에서도 설명했듯 네이버 클라우드에서 스토리지를 추가하여 생성할 때 최대 볼륨 크기는 2000GB로 제한되어 있습니다.

Linux 환경에서는 LVM(Logical Volume Manager)을 이용하여 최대 용량을 4TB, 6TB까지도 늘려보았습니다. 그렇다면 Windows 환경에서는 어떻게 파티션 최대 용량을 늘릴 것인가에 대해서 알아봅시다.


Adding capacity using storage pools

우선 위 이미지와 같이 서버에 추가할 스토리지 2개를 생성합니다.
2000GB 용량으로 2개의 스토리지를 생성해주었습니다.

이후 서버에 접속하여 아래 이미지만 순서대로 따라 해주면됩니다.
TIP이라면 중간에 뭔가 잘 안된다 싶으면 F5를 눌러 최신화 해줍시다.
설정한 것이 즉각 최신화가 안돼서 적용하려면 새로고침이 필요하더라구요…

서버 관리자에서 File and Storage Services로 클릭해줍시다.
Storage Pools 입장!!
TASKS – New Storage Pool
Next를 눌러서 넘어갑시다.
이름 정해주고 Next
추가할 물리적 디스크를 선택하고 Next를 눌러줍니다.
VIRTUAL DISKS 쪽에서 TASKS – New Virtual DISK를 눌러줍니다.
Storage Pool 선택 OK
Next 클릭
동일하게 이름 정해주고 Next를 눌러줍시다.

이 부분이 중요한데 Simple이 우리가 아는 RAID 0, Mirror가 RAID 1, Parity가 RAID 5입니다.
RAID에 대한 부분은 따로 설명하지 않으니 RAID가 궁금하실 경우 검색해보시면 자료가 많으니 찾아보시기 바랍니다.

여기서 Thin으로 해줬습니다. Fixed를 해주니 이후에 추가 확장이 정상적으로 되지 않는 증상이 발견되어 Thin으로 선택해주었습니다. 용량이 적을 때는 Fixed로 해도 추가 확장이 잘 되는데 2TB만 넘어가면 추가 확장이 되지 않습니다. 그런데 Thin으로 해주면 이후 2TB가 넘어가도 추가 확장이 가능합니다.

원하는 가상 디스크 크기를 설정 후 Next를 눌러줍니다.
Create를 눌러 생성해줍시다.
이어서 볼륨 생성까지 하게되는데 바로 Next를 눌러주면 됩니다.
이 부분도 Next를 눌러주면 됩니다.
볼륨 사이즈 지정해주고 Next!
Drive letter 설정 후 Next
파일시스템 및 레이블 설정 후 Next
이제 Create만 눌러주면 정상적으로 모든 작업이 마무리됩니다.
방금 생성한 4TB짜리 D드라이브 입니다.

위 작업 후 추가적인 테스트도 진행하였습니다.

RAID 0, RAID 1, RAID 5만 있어서 RAID 10은 RAID 1로 묶어주고 다시 0으로 묶어주는 작업을 해야하나? 싶어서 Storage Pool에서 1로 묶은 뒤 추가적으로 0으로 묶어주려고 했는데 Storage Pool에서는 그렇게 되지 않더라구요.

그런데 이게 diskmgmt.msc (디스크 관리)에서도 Span(JBOD), Simple(RAID 0), Mirror(RAID 1), Parity(RAID 5) 기능이 있단 말이죠?
Storage Pool에서 RAID 1로 묶은 두 디스크가 diskmgmt.msc (디스크 관리)에서 0으로 묶을 수 있길래 재미삼아 한번 해봤는데…

되긴 됩니다.. 그런데 이게 정상적이지는 않아보였습니다.😑
디스크 관리에서 RAID 1 디스크 2개를 0으로 추가로 묶어줄 때 12시간이 소요됐습니다.
무려 테스트는 200GB 디스크 4개로 했는데 상당히 오랜 시간이 소요된 것입니다.

이게 과연 정상적일까…🙄
이렇게 써보신 경험이 있으시다면 댓글로 공유해주세요~


Volume Expansion

자 이제 위에서 구성한 Storage Pool에서 파티션 크기를 더 확장 해보겠습니다.
기존 4TB에서 6TB로 확장하기 위해 스토리지 하나를 더 생성해주었습니다.

디스크 생성 및 추가 후 Storage Pool에서 위 이미지와 같이 Add Physical Disk를 선택해줍니다. 추가할 Disk가 보이지 않는 다면 F5를 눌러 최신화 해줍시다.

Add Physical DIsk

Physical Disk가 정상적으로 추가되면 이제 위 이미지처럼 Virtual Disks에서 Extend Virtual Disk를 선택하여 가상 디스크를 확장해주도록 합시다.

확장할 최대 크기를 입력해줍니다.

[윈도우 키+ R]을 누르신 후 diskmgmt.msc를 실행하여 디스크 관리를 켜줍니다.

위 이미지처럼 기존 4TB 디스크에서 Extend Volume을 눌러 디스크를 확장해주도록 합시다.

추가한 용량을 선택해주고 Next를 눌러줍니다.

Finish를 눌러 마무리 해주면 아래 이미지와 같이 정상적으로 5.85TB까지 크기가 확장된 것을 확인하실 수 있습니다.

Disk 확장 마무리 확인

Benchmark performance testing

이 포스팅을 준비하면서 Storage Pool을 이용하여 RAID를 묶었을 때 성능 테스트가 궁금해서 벤치마크 성능 테스트도 함께 해보았습니다. 벤치마크 툴은 ATTO Disk Benchmark 를 사용하였습니다.

Raid 설정을 하지 않은 일반 DISK
디스크를 2개를 SIMPLE (RAID 0)로 묶었을 때
디스크를 3개를 SIMPLE (RAID 0)로 묶었을 때

수치를 보면 확실히 디스크 3개를 RAID 0 으로 묶었을 때가 가장 Write/Read 수치가 높게 나왔습니다. 그런데 이 과정에 재밌는 사실을 하나 알아냈는데 디스크 3개를 RAID 0으로 묶었을 때와 디스크 2개를 RAID 0 으로 묶은 뒤 이후에 추가로 디스크를 1개 더 추가 확장하였을 때 동일한 용량인데 다른 수치를 보였습니다.

디스크 3개를 RAID 0 으로 묶었을 때
: I/O Size 64MB 기준 Write, Read = 264.37, 257.55 MB/s

디스크 2개를 RAID 0 으로 묶고 이후 디스크 1개를 추가 확장했을 때
: I/O Size 64MB 기준 Write, Read = 176.12, 169.78 MB/s

디스크 2개를 RAID 0 으로 묶었을 때
: I/O Size 64MB 기준 Write, Read = 175.34, 169.54 MB/s

RAID를 하지 않았을 때
: I/O Size 64MB 기준 Write, Read = 86.10, 85.05 MB/s

위와 같은 수치가 나왔었습니다.

애초에 처음 RAID를 잡을 때 크게 묶지 않는다면 이후 디스크를 추가하는 부분은 수치가 변하지 않는?…


Note

윈도우 Storage pool 역시 백업을 스냅샷이 아닌 이미지 생성으로 진행해야합니다.

이후 서버에 문제가 생겼을 때 생성된 이미지로 서버를 재생성하면 구성된 Storage pool까지 전부 그대로 올라오는데 스냅샷은 그렇게 되지 않습니다.

단, Linux 편에서도 언급했듯 이미지 백업으로 서버를 생성하면 서버 생성 시 스토리지 종류를 SSD로 선택할 경우 나머지 볼륨들도 전부 SSD로 생성된다는 점!!

OS는 SSD 추가 스토리지를 HDD로 나누어야할 경우 동일하게 서버 생성 후 구성하여 데이터를 복사해줘야합니다.


Personal Comments

여기까지 네이버 클라우드 윈도우 환경에서 2000GB를 초과하는 파티션도 마무리했습니다.

Storage Pool을 이용해서 software RAID를 구성하고 파티션 크기를 확장해보았는데 나름 괜찮은 것같습니다. 원하시는 구성에 맞춰서 RAID 0, RAID 1, RAID5 설정을 하셔서 사용하면 좋을 것같습니다.

긴 글 읽어주셔서 감사합니다.

NCP

[NCP] 네이버 클라우드에서 2TB 초과하는 파티션 사용하기 – Linux편

안녕하세요. ManVSCloud 김수현입니다.

오늘은 네이버 클라우드 Linux 환경에서 2TB 용량을 초과하는 파티션 사용법에 대해 포스팅하였습니다.

원래 Windows 부터 자료 다 준비해놨는데 포스팅 이미지들을 전부 회사에 두고온 관계로…
Linux편을 먼저 포스팅해보겠습니다.🙄

우선 테스트 환경와 어떻게 2TB를 초과하는 용량의 파티션을 생성할 것인가에 대해 알아보도록 합시다.


Environment and Description

📢 사용된 OS : centos-7.8-64

네이버 클라우드에서 스토리지를 추가하여 생성할 때 최대 볼륨 크기는 2000GB로 제한되어 있습니다.

그렇다면 어떻게 2000GB가 넘는 파티션을 생성할 것이냐?

우선 결론부터 말하자면 LVM(Logical Volume Manager)을 사용하여 파티션을 생성할 것입니다.

LVM에 대해 깊게 설명하는 포스팅은 아니니 간단하게 설명하자면 LVM을 이용한다면 여러 개의 물리적인 디스크 파티션을 논리적인 그룹으로 묶은 뒤 개별적인 논리 디스크로 할당하여 유연성있게 사용할 수 있습니다.

LVM에 대해 더 자세히 알고 싶으시다면 LVM에 대한 개념과 명령어에 대해 검색하여 확인 해보시기 바랍니다.


Create partitions using LVM

우선 위 이미지와 같이 서버에 추가할 스토리지 2개를 생성합니다.
2000GB 용량으로 2개의 스토리지를 생성해주었습니다.

[root@s17ab8051000 ~]# fdisk -l

Disk /dev/xvda: 53.7 GB, 53687091200 bytes, 104857600 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x000ac8f2

    Device Boot      Start         End      Blocks   Id  System
/dev/xvda1   *        2048     2099199     1048576   83  Linux
/dev/xvda2         2099200   104857599    51379200   83  Linux

Disk /dev/xvdb: 2147.5 GB, 2147483648000 bytes, 4194304000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/xvdc: 2147.5 GB, 2147483648000 bytes, 4194304000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

서버 내에서 fdisk -l 명령어로 확인해보면 추가된 두개의 스토리지를 확인할 수 있습니다.

[root@s17ab8051000 ~]# fdisk /dev/xvdb

Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-4194303999, default 2048): 
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-4194303999, default 4194303999): 
Using default value 4194303999
Partition 1 of type Linux and of size 2 TiB is set

fdisk /dev/xvdb 를 이용하여 파티션을 생성해줍시다.

1. n을 눌러 새로 생성해줍니다.
2. p를 눌러 주 파티션을 생성해줍니다.
3. 파티션 넘버를 정해주는데 default가 1로 되어있어 그냥 엔터만 쳐도 됩니다.
4. First sector는 섹터 시작점 Last sector는 섹터가 끝나는 부분을 지정해주는 건데 그냥 엔터를 눌러주어 전체 용량 지정해줍시다.

Command (m for help): t
Selected partition 1
Hex code (type L to list all codes): l

 0  Empty           24  NEC DOS         81  Minix / old Lin bf  Solaris        
 1  FAT12           27  Hidden NTFS Win 82  Linux swap / So c1  DRDOS/sec (FAT-
 2  XENIX root      39  Plan 9          83  Linux           c4  DRDOS/sec (FAT-
 3  XENIX usr       3c  PartitionMagic  84  OS/2 hidden C:  c6  DRDOS/sec (FAT-
 4  FAT16 <32M      40  Venix 80286     85  Linux extended  c7  Syrinx         
 5  Extended        41  PPC PReP Boot   86  NTFS volume set da  Non-FS data    
 6  FAT16           42  SFS             87  NTFS volume set db  CP/M / CTOS / .
 7  HPFS/NTFS/exFAT 4d  QNX4.x          88  Linux plaintext de  Dell Utility   
 8  AIX             4e  QNX4.x 2nd part 8e  Linux LVM       df  BootIt         
 9  AIX bootable    4f  QNX4.x 3rd part 93  Amoeba          e1  DOS access     
 a  OS/2 Boot Manag 50  OnTrack DM      94  Amoeba BBT      e3  DOS R/O        
 b  W95 FAT32       51  OnTrack DM6 Aux 9f  BSD/OS          e4  SpeedStor      
 c  W95 FAT32 (LBA) 52  CP/M            a0  IBM Thinkpad hi eb  BeOS fs        
 e  W95 FAT16 (LBA) 53  OnTrack DM6 Aux a5  FreeBSD         ee  GPT            
 f  W95 Ext'd (LBA) 54  OnTrackDM6      a6  OpenBSD         ef  EFI (FAT-12/16/
10  OPUS            55  EZ-Drive        a7  NeXTSTEP        f0  Linux/PA-RISC b
11  Hidden FAT12    56  Golden Bow      a8  Darwin UFS      f1  SpeedStor      
12  Compaq diagnost 5c  Priam Edisk     a9  NetBSD          f4  SpeedStor      
14  Hidden FAT16 <3 61  SpeedStor       ab  Darwin boot     f2  DOS secondary  
16  Hidden FAT16    63  GNU HURD or Sys af  HFS / HFS+      fb  VMware VMFS    
17  Hidden HPFS/NTF 64  Novell Netware  b7  BSDI fs         fc  VMware VMKCORE 
18  AST SmartSleep  65  Novell Netware  b8  BSDI swap       fd  Linux raid auto
1b  Hidden W95 FAT3 70  DiskSecure Mult bb  Boot Wizard hid fe  LANstep        
1c  Hidden W95 FAT3 75  PC/IX           be  Solaris boot    ff  BBT            
1e  Hidden W95 FAT1 80  Old Minix   
Hex code (type L to list all codes): 8e
Changed type of partition 'Linux' to 'Linux LVM'

Command (m for help): w

이어서 해당 파티션의 타입을 지정해주어야하는데 타입의 종류는 l(L)을 입력하여 타입에 대한 모든 Hex code를 볼 수 있습니다.
우리는 Linux LVM을 사용해야하니 8e를 사용 해줄 것입니다.

5. t를 입력하여 파티션 타입 지정
6. 8e 입력하여 Linux LVM로 지정해줍니다.
7. w (저장)

위 과정을 추가한 두 디스크 /dev/xvdb, /dev/xvdc 모두 설정해주어야 합니다.

[root@s17ab8051000 ~]# fdisk -l

Disk /dev/xvda: 53.7 GB, 53687091200 bytes, 104857600 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x000ac8f2

    Device Boot      Start         End      Blocks   Id  System
/dev/xvda1   *        2048     2099199     1048576   83  Linux
/dev/xvda2         2099200   104857599    51379200   83  Linux

Disk /dev/xvdb: 2147.5 GB, 2147483648000 bytes, 4194304000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x09ecabef

    Device Boot      Start         End      Blocks   Id  System
/dev/xvdb1            2048  4194303999  2097150976   8e  Linux LVM

Disk /dev/xvdc: 2147.5 GB, 2147483648000 bytes, 4194304000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x0a3c26f7

    Device Boot      Start         End      Blocks   Id  System
/dev/xvdc1            2048  4194303999  2097150976   8e  Linux LVM

두 스토리지 전부 정상적으로 생성했다면 /dev/xvdb1, /dev/xvdc1가 Linux LVM으로 잘 생성된 것을 확인할 수 있습니다.

[root@s17ab8051000 ~]# rpm -qa | grep lvm2
lvm2-libs-2.02.186-7.el7_8.2.x86_64
lvm2-2.02.186-7.el7_8.2.x86_64

이제 논리적 볼륨으로 관리해줄 것입니다.
lvm2가 설치되어 있어야하지만 네이버 클라우드에서는 이미 설치가 되어 있었습니다.

[root@s17ab8051000 ~]# pvcreate /dev/xvdb1
  Physical volume "/dev/xvdb1" successfully created.
[root@s17ab8051000 ~]# pvcreate /dev/xvdc1
  Physical volume "/dev/xvdc1" successfully created.

pvcreate 명령어를 이용하여 fdisk로 만든 파티션을 물리적 볼륨(PV)으로 생성해줍니다.

[root@s17ab8051000 ~]# pvdisplay
  "/dev/xvdb1" is a new physical volume of "1.95 TiB"
  --- NEW Physical volume ---
  PV Name               /dev/xvdb1
  VG Name               
  PV Size               1.95 TiB
  Allocatable           NO
  PE Size               0   
  Total PE              0
  Free PE               0
  Allocated PE          0
  PV UUID               gcpy02-Fe7l-4Klb-pQed-z726-sgmY-JQXe6R
   
  "/dev/xvdc1" is a new physical volume of "1.95 TiB"
  --- NEW Physical volume ---
  PV Name               /dev/xvdc1
  VG Name               
  PV Size               1.95 TiB
  Allocatable           NO
  PE Size               0   
  Total PE              0
  Free PE               0
  Allocated PE          0
  PV UUID               I6W7l7-Rxce-QllJ-n6nl-nULX-PZ3j-PQGJe3

pvdisplay 명령어를 이용하여 생성된 PV를 자세히 볼 수 있습니다. (pvs, pvscan 명령어를 사용해도 좋습니다.)

[root@s17ab8051000 ~]# vgcreate vg_data /dev/xvdb1 /dev/xvdc1
  Volume group "vg_data" successfully created

[root@s17ab8051000 ~]# vgdisplay
  --- Volume group ---
  VG Name               vg_data
  System ID             
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  1
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               <3.91 TiB
  PE Size               4.00 MiB
  Total PE              1023998
  Alloc PE / Size       0 / 0   
  Free  PE / Size       1023998 / <3.91 TiB
  VG UUID               Kl29bl-HIIm-NXxt-RPRI-1mfr-VMtO-0qOO7I

PV 생성 후에 VG, 즉 볼륨 그룹을 생성해주어야합니다.
vgcreate 명령어로 위와 같이 볼륨 그룹을 생성해줍시다.
vgcreate VG 이름 디바이스명1 디바이스명2 과같이 사용할 수 있습니다.

[root@s17ab8051000 ~]# lvcreate -l 100%FREE -n lv_data vg_data
  Logical volume "lv_data" created.

[root@s17ab8051000 ~]# lvdisplay
  --- Logical volume ---
  LV Path                /dev/vg_data/lv_data
  LV Name                lv_data
  VG Name                vg_data
  LV UUID                66UDwi-kBvC-lJFc-Nc0g-QcSA-dxJL-0eYTUG
  LV Write Access        read/write
  LV Creation host, time s17ab8051000, 2021-07-18 15:30:36 +0900
  LV Status              available
  # open                 0
  LV Size                <3.91 TiB
  Current LE             1023998
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     8192
  Block device           253:0

VG으로 물리적 볼륨을 하나로 묶어주었습니다.
생성된 VG에서 여러개의 LV로 또는 하나의 LV로 생성하실 수 있습니다.
lvcreate로 논리적 볼륨(LV)를 생성해줄 것입니다.
-l 옵션은 PE 단위이며 -L 옵션은 MB, GB, TB 단위입니다.
(사용할 수 있는 PE와 용량은 vgdisplay 명령어에서 Free PE / Size 를 확인하면 볼 수 있습니다.)

lvcreate -l 100%FREE 를 주고 -n 옵션으로 lv의 이름을 지정해줬습니다 이후 위에서 생성했던 vg의 이름을 써줍니다.

[root@s17ab8051000 ~]# mkfs.xfs /dev/vg_data/lv_data
meta-data=/dev/vg_data/lv_data   isize=512    agcount=4, agsize=262143488 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0, sparse=0
data     =                       bsize=4096   blocks=1048573952, imaxpct=5
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=511999, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

이제 마지막으로 파일시스템 작업과 마운트 작업만 해주면 끝입니다.
저는 xfs 파일시스템으로 포맷해줬는데 이 부분은 원하시는 파일시스템으로 포맷해주시면 됩니다.

[root@s17ab8051000 ~]# mkdir /data
[root@s17ab8051000 ~]# mount /dev/vg_data/lv_data /data
[root@s17ab8051000 ~]# df -h /data
Filesystem                   Size  Used Avail Use% Mounted on
/dev/mapper/vg_data-lv_data  4.0T   33M  4.0T   1% /data

위와 같이 생성한 디렉토리에 마운트까지 정상적으로 완료되었습니다.
하지만 최종적으로 부팅 후에도 정상적으로 마운트되려면 /etc/fstab 파일을 수정해주어야합니다.

[root@s17ab8051000 ~]# blkid /dev/vg_data/lv_data
/dev/vg_data/lv_data: UUID="4240c1b1-ac89-477c-933b-eff8db839adf" TYPE="xfs" 

blkid 명령어로 UUID를 확인하고 /etc/fstab 파일에 아래와 같이 추가해주었습니다.

#
# /etc/fstab
# Created by anaconda on Mon Aug 31 14:44:01 2020
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=0692fdb8-bb3c-4094-83f0-fe95a339b8c1 /                       xfs     defaults        0 0
UUID=f95bed0a-11af-4b2c-bfcc-4afb91a68fc1 /boot                   xfs     defaults        0 0
UUID=4240c1b1-ac89-477c-933b-eff8db839adf /data                   xfs     defaults        0 0

네이버 클라우드에서 2TB가 초과되는 파티션을 사용하는 것 생각보다 쉽지 않나요?

그럼 이제 이렇게 논리적으로 생성한 볼륨을 확장하는 방법도 알아봅시다.
4TB의 용량도 다 써버려서 확장이 필요할 때 이미 생성된 LV는 추가적인 확장이 가능할까요?


Volume Expansion

LV 확장은 충분히 가능합니다. 아래 예시로 준비하였습니다.

먼저 2000GB 크기의 스토리지를 하나 더 추가 생성하였습니다.

[root@s17ab8051000 ~]# fdisk /dev/xvdd
Welcome to fdisk (util-linux 2.23.2).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table
Building a new DOS disklabel with disk identifier 0x5840d763.

Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Partition number (1-4, default 1): 
First sector (2048-4194303999, default 2048): 
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-4194303999, default 4194303999): 
Using default value 4194303999
Partition 1 of type Linux and of size 2 TiB is set

Command (m for help): t
Selected partition 1
Hex code (type L to list all codes): 8e
Changed type of partition 'Linux' to 'Linux LVM'

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

위에서 배운 그대로 fdisk를 이용하여 파티션을 생성해줍니다.

[root@s17ab8051000 ~]# pvcreate /dev/xvdd1
  Physical volume "/dev/xvdd1" successfully created.

[root@s17ab8051000 ~]# vgdisplay
  --- Volume group ---
  VG Name               vg_data
  System ID             
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  2
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               <3.91 TiB
  PE Size               4.00 MiB
  Total PE              1023998
  Alloc PE / Size       1023998 / <3.91 TiB
  Free  PE / Size       0 / 0   
  VG UUID               Kl29bl-HIIm-NXxt-RPRI-1mfr-VMtO-0qOO7I
   
[root@s17ab8051000 ~]# 
[root@s17ab8051000 ~]# vgextend vg_data /dev/xvdd1
  Volume group "vg_data" successfully extended

자 여기서부터가 중요한데 pvcreate를 이용하여 PV를 생성해주는 것까지는 동일합니다.
하지만 이번엔 볼륨 그룹을 따로 생성해주지 않았습니다.
볼륨 그룹을 따로 생성할 수도 있겠지만 vgextend를 이용하여 기존 볼륨 그룹을 확장하는 방식으로 해보았습니다.

[root@s17ab8051000 ~]# vgdisplay
  --- Volume group ---
  VG Name               vg_data
  System ID             
  Format                lvm2
  Metadata Areas        3
  Metadata Sequence No  3
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                3
  Act PV                3
  VG Size               <5.86 TiB
  PE Size               4.00 MiB
  Total PE              1535997
  Alloc PE / Size       1023998 / <3.91 TiB
  Free  PE / Size       511999 / 1.95 TiB
  VG UUID               Kl29bl-HIIm-NXxt-RPRI-1mfr-VMtO-0qOO7I
   

[root@s17ab8051000 ~]# lvextend -l +511999 /dev/vg_data/lv_data
  Size of logical volume vg_data/lv_data changed from <3.91 TiB (1023998 extents) to <5.86 TiB (1535997 extents).
  Logical volume vg_data/lv_data successfully resized.

vgdisplay를 이용해서 보면 정상적으로 VG가 확장되어 Free PE / Size가 추가적으로 여유가 생긴 것을 확인할 수 있습니다.

여기서 lvextend 명령어를 이용해줍시다!
lvextend를 이용하면 논리적 볼륨을 확장할 수 있습니다.
이번엔 -l 명령어로 PE를 지정해서 줘봅시다. (1PE 당 4MB의 용량이라고 합니다.)

[root@s17ab8051000 ~]# lvscan
  ACTIVE            '/dev/vg_data/lv_data' [<5.86 TiB] inherit
[root@s17ab8051000 ~]# df -h /data
Filesystem                   Size  Used Avail Use% Mounted on
/dev/mapper/vg_data-lv_data  4.0T   33M  4.0T   1% /data

끝이 아닙니다.
LV는 확장되었지만 df 명령어로 보면 그대로 전체 크기가 4T로 머물러 있을 것입니다.

왜냐? 파일시스템을 확장해주지 않았으니까…

[root@s17ab8051000 ~]# xfs_growfs -d /data
meta-data=/dev/mapper/vg_data-lv_data isize=512    agcount=4, agsize=262143488 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0 spinodes=0
data     =                       bsize=4096   blocks=1048573952, imaxpct=5
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal               bsize=4096   blocks=511999, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 1048573952 to 1572860928
[root@s17ab8051000 ~]# 
[root@s17ab8051000 ~]# df -h /data
Filesystem                   Size  Used Avail Use% Mounted on
/dev/mapper/vg_data-lv_data  5.9T   33M  5.9T   1% /data

xfs_growfs 명령어로 위와 같이 파일시스템을 확장해줄 수 있습니다.
※ 파일시스템이 EXT4일 경우 resize2fs 명령어를 사용할 수 있습니다.

파일시스템 확장 후 df 명령어로 다시 확인 해보면 정상적으로 6T까지 용량이 늘어난 것을 볼 수 있습니다.


Note

이렇게 스토리지 LVM을 이용하여 파티션을 구성했을 경우 백업을 스냅샷 백업이 아닌 이미지 백업으로 해야합니다.

이후 서버에 문제가 생겼을 때 생성된 이미지로 서버를 재생성하면 구성된 LVM까지 전부 다 그대로 올라오는데 스냅샷은 그렇게 할 수 없습니다.
스토리지 여러개를 하나로 묶어 놓았는데 스냅샷으로 백업해버리면 스냅샷으로 볼륨 생성 후 이걸 다시 묶어주고 파일시스템을 포맷하면 데이터가 살아있지 못하죠..

단 이미지 백업으로 서버를 생성하면 서버 생성 시 스토리지 종류를 SSD로 선택할 경우 나머지 볼륨들도 전부 SSD로 생성된다는 점이죠…

나머지 볼륨들을 다시 HDD로 변경하려면 스토리지를 HDD로 생성 하고 LVM으로 PV,VG, LV전부 구성 해준 뒤 데이터를 복사해줘야합니다…😥


Personal Comments

지금까지 네이버 클라우드 리눅스 환경에서 2000GB를 초과하는 파티션을 만들어보았습니다.
오늘 설명드린 LVM을 이용한 파티션 생성 및 확장 뿐만이 아니라 축소, 스냅샷 등 다양하게 사용할 수 있으니 관심있으시면 다양하게 써보시면 좋을 것같습니다.

Windows편도 금방 포스팅하도록 하겠습니다.

긴 글 읽어주셔서 감사합니다.

NCP

[NCP] Container Registry에서 이미지를 가져오기 & 로드밸런서 연결

안녕하세요. ManVSCloud 김수현입니다.

오늘은 Naver Cloud Platform에서 Container Registry에서 이미지를 가져오는 방법과 Load Balancer에 연결하는 방법을 알아보도록 하겠습니다.


CONTAINER REGISTRY에서 이미지를 가져오기

아직 Container Registry를 생성해본 적이 없으시다면 위 [NAVER CLOUD KUBERNETES – CONTAINER REGISTRY로 컨테이너 이미지를 관리]를 먼저 보고 오시기 바랍니다.

위 포스팅에서는 push를 해보았습니다. 오늘은 pull을 해볼 시간입니다.

우선 테스트용으로 하고 계시다면 이전에 했던 docker image를 전부 지우고 한 번 해보도록합시다.

[root@kubernetes-server-kr2 ~]# docker rm `docker ps -a -q`
[root@kubernetes-server-kr2 ~]# docker rmi -f `docker images -q`

docker login을 해줍시다.

[root@kubernetes-server-kr2 ~]# docker login <CONTAINER REGISTRY에 나와있는 엔드포인트>
Authenticating with existing credentials...
WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded

docker pull 엔드포인트/이미지:버전 명령어로 docker 이미지를 가져올 수 있습니다.

[root@kubernetes-server-kr2 ~]# docker pull manvscloud-k8s-cr.kr.ncr.ntruss.com/manvscloud-apache:1.0
1.0: Pulling from manvscloud-apache
2d473b07cdd5: Pull complete 
444a3233aeea: Pull complete 
Digest: sha256:b2e60515712f6c5d4f155e9d234299fa82640d8dc7766405fe997c1b80658c07
Status: Downloaded newer image for manvscloud-k8s-cr.kr.ncr.ntruss.com/manvscloud-apache:1.0
manvscloud-k8s-cr.kr.ncr.ntruss.com/manvscloud-apache:1.0

또한 k8s에서 secret을 이용한다면 패스워드, OAuth 토큰, ssh 키와 같은 정보를 저장 및 관리할 수 있는데 이를 이용하여 pod를 생성해보도록 합시다.

[root@kubernetes-server-kr2 ~]# kubectl get secret
NAME                  TYPE                                  DATA   AGE
default-token-p5mq2   kubernetes.io/service-account-token   3      11d

kubectl create secret docker-registry “secret 이름” –docker-server=레지스트리-엔드포인트 –docker-username=Access-Key-ID –docker-password=Secret-Key –docker-email=계정으로 아래와 같이 secret을 만들 수 있습니다.

[root@kubernetes-server-kr2 ~]# kubectl create secret docker-registry manvscloud-sec --docker-server=레지스트리-엔드포인트 --docker-username=Access-Key-ID --docker-password=Secret-Key --docker-email=계정

[root@kubernetes-server-kr2 ~]# kubectl get secret
NAME                  TYPE                                  DATA   AGE
default-token-p5mq2   kubernetes.io/service-account-token   3      11d
manvscloud-sec        kubernetes.io/dockerconfigjson        1      19s

이제 yaml 파일을 생성하여 위에서 생성한 secret을 이용하여 이미지를 pull 및 pod 생성을 해봅시다.

vi apache.yaml

apiVersion: v1
kind: Pod
metadata:
 name: manvscloud-apache
 namespace: default
spec:
 containers:
 - name: manvscloud-apache
   image: manvscloud-k8s-cr.kr.ncr.ntruss.com/manvscloud-apache:1.0
 imagePullSecrets:
 - name: manvscloud-sec
[root@kubernetes-server-kr2 ~]# kubectl create -f apache.yaml 
pod/manvscloud-apache created

[root@kubernetes-server-kr2 ~]# kubectl get pods
NAME                                 READY   STATUS    RESTARTS   AGE
manvscloud-apache                    1/1     Running   0          4s

CONTAINER REGISTRY에 있는 이미지를 잘 가져와 pod가 생성되었습니다.
이렇게 CONTAINER REGISTRY를 이용하여 이미지 배포 관리가 쉽게 가능합시다.

또한 CONTAINER REGISTRY에서 Configuration을 클릭하여 Public Endpoint를 활성화/비활성화 선택이 가능합니다. 네이버 클라우드 내부에서만 사용할 것이라면 비활성화 하는 것이 좋습니다.


로드밸런서 연결

네이버 클라우드 Kubernetes Service를 사용중이라면 서비스 생성 시에 type을 LoadBalancer로 지정할 경우 네이버 클라우드 콘솔 내에 로드밸런서 인스턴스가 자동으로 생성됩니다.

로드밸런서 설정의 경우 어노테이션으로 설정할 수 있습니다.

"metadata": {
  "annotations": {
    "key1" : "value1",
    "key2" : "value2"
  }
}
https://guide.ncloud-docs.com/docs/nks-nks-1-8

실습을 통해 직접 로드밸런서를 생성해봅시다.
이번 실습에서는 어노테이션을 이용하여 추가적인 설정은 하지 않았습니다.
간단하게 로드밸런서 연결만 따라할 수 있도록 해두었습니다.

vi manvscloud-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
 name: apache-deployment
spec:
 replicas: 3
 selector:
   matchLabels:
     app: apache
 template:
   metadata:
     labels:
       app: apache
   spec:
     containers:
     - name: apache
       image: manvscloud-k8s-cr.kr.ncr.ntruss.com/manvscloud-apache:1.0
       ports:
       - containerPort: 80
     imagePullSecrets:
     - name: manvscloud-sec

아래와 같이 kubectl get pods –show-labels 했을 때 LABELS이 붙어있을 것입니다.
replicas, label 등은 따로 쿠버네티스에 대한 공부가 필요하니 이러한 설정에 이해가 어려우신 분들은 우선 kubernetes에 대한 공부를 우선적으로 간단하게나마 하시는 것을 권장드립니다.

[root@kubernetes-server-kr2 ~]# kubectl get pods --show-labels
NAME                                 READY   STATUS    RESTARTS   AGE   LABELS
apache-deployment-75895cbcbb-6dlvz   1/1     Running   0          14s   app=apache,pod-template-hash=75895cbcbb
apache-deployment-75895cbcbb-l7q4d   1/1     Running   0          14s   app=apache,pod-template-hash=75895cbcbb
apache-deployment-75895cbcbb-vcvpq   1/1     Running   0          14s   app=apache,pod-template-hash=75895cbcbb

[root@kubernetes-server-kr2 ~]# for pod in $(kubectl get pod -l app=apache |awk 'NR>1 {print $1}'); do kubectl exec $pod -- /bin/sh -c "hostname > /var/www/html/index.html; echo '안녕하세요. ManVSCloud입니다.' >> /var/www/html/index.html"; done

각 pod 내 index.html 파일을 수정해주었습니다.
로드밸런서를 연결하여 접속하기 위해 LoadBalancer를 생성해봅시다.

아래와 같이 Serivces yaml을 생성합니다.

vi lb.yaml

kind: Service
apiVersion: v1
metadata:
 name: lb-service
spec:
 ports:
   - port: 80
     targetPort: 80
 selector:
   app: apache
 type: LoadBalancer
[root@kubernetes-server-kr2 ~]# kubectl create -f lb.yaml 
service/lb-service created

kubectl get services 명령어로 확인해보면 EXTERNAL-IP가 NCP 내 LB로 되어있는 것을 확인할 수 있습니다.

[root@kubernetes-server-kr2 ~]# kubectl get services
NAME         TYPE           CLUSTER-IP      EXTERNAL-IP                                                        PORT(S)        AGE
kubernetes   ClusterIP      198.19.128.1    <none>                                                             443/TCP        11d
lb-service   LoadBalancer   198.19.208.51   default-lb-service-821a9-7191539-4b535e410da7.kr.lb.naverncp.com   80:31033/TCP   5m33s

콘솔을 보면 따로 Load Balancer를 생성해주지 않았는데 따로 콘솔상에서 생성되어 있는 것을 확인할 수 있습니다. 삭제도 마찬가지입니다.
kubectl delete svc lb-service를 해주면 콘솔상에서도 자동 제거가 됩니다.

생성된 LB의 접속 정보를 이용하여 웹에서 접속해보면 위에서 추가해준 index.html의 값이 나오고 있습니다.

로드밸런싱 알고리즘은 기본값인 Round Robin으로 설정되어 있으며 Least Connection과 Source IP Hash로도 변경이 가능합니다.


Personal Comments

오늘은 CONTAINER REGISTRY에서 이미지를 가져오는 방법과 로드밸런싱 연동 방법을 알아보았습니다.

참고로 실습 과정을 따라해보실 경우 .yaml 파일을 그대로 복사하지 마시고 엔드포인트를 잘 수정하여 사용하시기 바랍니다.

긴 글 읽어주셔서 감사합니다.

함께 보며 공부하기 좋은 자료