Browsing Tag

네이버

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

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

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

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

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


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] Intermediate 보안 강화 교육 후기

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

네이버 클라우드에서 올해 1월부터 6월까지 Intermediate 교육 코스 중
마지막 Security 교육이 종료되었습니다.

Intermediate 교육 중에 Big Data 교육을 듣지못해 아쉬움이 있습니다.😥
나머지 5개의 교육은 다 들었는데 제가 아직 접해보지 못한 개발과 AI까지 모두 도움이 되는 교육이었습니다.

1월 – Big Data
2월 – Kubenetes
3월 – DevOps
4월 – Media
5월 – A.I
6월 – Security

6월 18일에 있었던 보안 강화 교육은 개인적으로 가장 중요하고 권장하는 교육이라고 생각합니다.

저 역시 시간이 될 때마다 “[NCP] 네이버 클라우드에서의 보안” 시리즈로 포스팅 중인데 그 만큼 보안은 이제 선택이 아닌 필수 항목이기때문입니다.


Review

Naver Cloud Intermediate 보안 강화 교육

교육은 간단한 용어 정리부터 시작해서 해킹 사례, 해킹 패턴, 보안 강화 등으로 이루어져있었습니다.

또한 ACG나 NACL 등은 많이 접하게 되기에 익숙하지만 Web Security Checker와 같은 서비스는 개인이 테스트로 사용하기에 비용 부담이 있을 수 있는데 해당 교육에서 사용하는 방법을 직접 보여주고 어떤 씩으로 결과가 나오는지 보여줍니다.

물론 Sub Account 및 API Key 에 대한 보안은 다루지 않았지만 서비스를 하는데에 있어 좋은 교육이었다고 생각합니다.


Personal Comments

이번 Security 교육에서는 실습용 계정을 주지않아 따로 실습은 진행하지 않았습니다.
추가적인 보안 실습에 관한 내용은 추가적인 포스팅으로 다루도록 하겠습니다.

현재 포스팅하고 있는 “네이버 클라우드에서의 보안” 시리즈가 생각보다 리소스 비용이 발생하는 것들이 꽤 많이 남아있어 어떻게 포스팅할지 고민 중이었는데 이번 교육으로 어느정도 이미지를 확보하여 참고할 수 있게 되었습니다.

1~6월 Intermediate 교육이 끝났습니다.
7~12월에도 있을까하고 늘 [교육 및 행사 일정]을 보고있는데 아직 예정이 없는듯보입니다

추가로 현재 [교육 및 행사 일정]을 보니 처음 네이버 클라우드를 접하시는 분들에게 추천하는 웨비나 하나를 발견했습니다.
“Follow-me! 클라우드 인프라 구축 기본편” 웨비나 입니다.
6월 24일에 있는데 네이버 클라우드를 시작해보고 싶으시다면 신청해서 한번 들어보시기 바랍니다.

후기 읽어주셔서 감사합니다.

NCP

[NCP] Naver CLoud에서 Kubernetes를 사용해보자 – NKS

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

DKOS(Docker Kubernetes Online Study) 2주차 과정을 마쳤습니다.

가상 머신, 물리 서버, AWS, Azure 환경에서 k8s 클러스터를 배포하는 것을 스터디하였지만 Naver Cloud Platform에서 k8s 클러스터를 배포하는 방법은 따로 스터디 하지 않아 이에 대해 공유하고자 오늘은 네이버 클라우드에서 k8s 클러스터 배포와 사용에 대해 알아보도록 하겠습니다.


Classic

우선 Classic 환경에서는 현재 Kubernetes Service 사용이 불가능합니다.

2021년 03월 04일까지만 사용할 수 있었고 현재는 사용 불가능하므로 저는 VPC 환경에서 Kubernetes Service 사용법에 대해 써보도록 하겠습니다.


VPC – VPC & Subnet 생성

우선 Naver Cloud Platform에서 VPC 환경을 사용하시려면 VPC 생성하여 서브넷 구성을 해주셔야합니다. 기존 AWS나 Azure와 같은 퍼블릭 클라우드 사용 경험이 많으시다면 이를 구성하는데에 큰 어려움이 없으실 것이라 생각합니다.

저는 위 이미지와 같이 생성해주었습니다.
오늘 포스팅에서는 LB까지는 사용하지 않지만 Naver Cloud 에서 k8s 클러스터 배포 시 가장 기본이 되는 서브넷 구성이라고 볼 수 있겠습니다.


VPC – Server

우선 서버를 생성해줍니다.
해당 서버 내에서 이후 생성할 각 클러스터들을 컨트롤 해줄 것입니다.

OS는 CentOS나 Ubuntu 아무것이나 괜찮습니다.

해당 서버의 패스워드 확인 후 서버로 접속해줍니다.
이후 아래 명령어를 이용하여 kubectl과 docker를 설치해줍시다.

[root@kubernetes-server-kr2 ~]# cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF

가끔 gpgkey 부분을 엔터쳐서 다음 줄로 내려버리시는 경우가 있는데 정상 설치가 안되니 아래 이미지와 같이 되게 해주세요.

/etc/yum.repos.d/kubernetes.repo
[root@kubernetes-server-kr2 ~]# yum install -y kubectl

//yum-utils device-mapper-persistent-data lvm2는 이미 설치가 되어있어서 따로 설치해줄 필요가 없었습니다.

[root@kubernetes-server-kr2 ~]# yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
[root@kubernetes-server-kr2 ~]# yum install -y docker-ce
[root@kubernetes-server-kr2 ~]# systemctl enable --now docker

VPC – NKS Cluster

이제 Kubernetes Service를 생성해줄 것입니다.

NKS 클러스터는 현재 1.17과 1.18 버전을 지원하고 있습니다.
또한 Pod Security Policy, Audit Log는 클러스터 생성 후에도 수정할 수 있으니 이후에 설정하셔도 됩니다.

생성 중에 NAT Gateway를 생성하라는 메시지가 발생합니다.
이는 왜 NAT Gateway를 생성해야하는지에 대해 아래 내용에서 보여드리기위해 따로 NAT Gateway를 먼저 설정해두지 않았습니다.

일단 넘어갑시다.

원하시는 서버 스펙과 노드 수를 정해준 뒤 추가해주면 클러스터가 생성됩니다.
해당 클러스터 생성에는 다소 시간이 소요됩니다.


VPC – Practice

이제 생성한 Server와 각 k8s 클러스터들을 이용하여 실습을 해보도록 하겠습니다.
우선 Server에서 생성한 k8s 클러스터를 컨트롤하기 위해서는 kubernetes service에서 생성한 클러스터들을 설정파일을 다운로드 해야합니다.

위 이미지와 같이 해당 설정파일을 다운로드 한 뒤에 Server로 넣어줍시다.
간단하게 마우스 이동으로 파일을 옮기시려면 lrzsz 를 설치하여 PC와 서버 간에 간단하게 파일을 업로드, 다운로드를 하실 수 있습니다.

yum install lrzsz

설정파일이 Server에 있는데 이는 아래와 같이 사용할 수 있습니다.

kubectl –kubeconfig=/root/kubeconfig-d1f34144-76a5-46fa-a55c-7186946b8acc.yaml get nodes

원래 kubectl get nodes인데 config 파일을 이용하여 클러스터 접근 구성을 하게 되는 것입니다.
하지만 매번 명령어 입력마다 이렇게 사용할 수는 없으니 alias 설정을 해준다면 더욱 편리하게 사용할 수 있습니다.

[root@kubernetes-server-kr2 ~]# ll
total 8
-rw-r--r-- 1 root root 5538 Jun 17 02:19 kubeconfig-d1f34144-76a5-46fa-a55c-7186946b8acc.yaml


[root@kubernetes-server-kr2 ~]# kubectl --kubeconfig=/root/kubeconfig-d1f34144-76a5-46fa-a55c-7186946b8acc.yaml get nodes
NAME                  STATUS   ROLES    AGE     VERSION
nks-pool-1003-w-eoi   Ready    <none>   9m23s   v1.18.17
nks-pool-1003-w-eoj   Ready    <none>   9m22s   v1.18.17

[root@kubernetes-server-kr2 ~]# cat << EOF >> .bash_profile 
> alias kubectl='kubectl --kubeconfig="/root/kubeconfig-d1f34144-76a5-46fa-a55c-7186946b8acc.yaml"'
> EOF
[root@kubernetes-server-kr2 ~]# source .bash_profile
https://hub.docker.com/

위 이미지는 docker hub입니다.
이전에 업로드 해둔 manvscloud_dkos 파일을 배포해보겠습니다.

[root@kubernetes-server-kr2 ~]# kubectl run manvscloud --image seevirus/manvscloud_dkos:1
pod/manvscloud created
[root@kubernetes-server-kr2 ~]# kubectl get pod
NAME         READY   STATUS              RESTARTS   AGE
manvscloud   0/1     ContainerCreating   0          13s
[root@kubernetes-server-kr2 ~]# kubectl get pod
NAME         READY   STATUS         RESTARTS   AGE
manvscloud   0/1     ErrImagePull   0          22s

ErrImagePull 메시지가 발생했습니다.
왜 도커 이미지를 Pull 해오지 못한걸까요?

원인은 바로 위에서 NAT Gateway를 설정해주지 않았기때문입니다.
위에서 클러스터 생성 시 “아웃바운드 인터넷 트래픽을 활성화하기 위해서는
NAT Gateway를 반드시 생성해야한다”
라고 알려주는 메시지는 바로 NAT Gateway 설정을 해주지 않게되면 아웃바운드 인터넷 트래픽 통신이 전혀 되지 않기때문이죠.

바로 NAT Gateway를 생성해줍시다.
생성한 NAT Gateway는 Private Route Table에 연결해주어야합니다.

위 이미지와 같이 NAT Gateway를 연결해주고 다시 Server로 돌아와서 확인해보도록 합시다.

[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   30m
[root@kubernetes-server-kr2 ~]# kubectl get pods -o wide
NAME         READY   STATUS    RESTARTS   AGE   IP             NODE                  NOMINATED NODE   READINESS GATES
manvscloud   1/1     Running   0          17m   198.18.0.169   nks-pool-1003-w-eoj   <none>           <none>

ErrImagePull이었던 상태가 Running 상태로 변경되어있습니다.
정상적으로 배포가 되었군요.

[root@kubernetes-server-kr2 ~]# kubectl get all --all-namespaces
NAMESPACE     NAME                                   READY   STATUS    RESTARTS   AGE
default       pod/manvscloud                         1/1     Running   0          17m
kube-system   pod/cilium-jv5gz                       1/1     Running   0          30m
kube-system   pod/cilium-monitor-jp82w               1/1     Running   0          27m
kube-system   pod/cilium-monitor-nbvgm               1/1     Running   0          27m
kube-system   pod/cilium-operator-78f6b5db7c-77gqn   1/1     Running   0          30m
kube-system   pod/cilium-operator-78f6b5db7c-pjthh   1/1     Running   0          30m
kube-system   pod/cilium-z6gbh                       1/1     Running   0          30m
kube-system   pod/coredns-7895d49695-7cjhm           1/1     Running   0          29m
kube-system   pod/coredns-7895d49695-csj5w           1/1     Running   0          29m
kube-system   pod/csi-nks-controller-0               6/6     Running   1          28m
kube-system   pod/csi-nks-node-jtg5t                 3/3     Running   1          28m
kube-system   pod/csi-nks-node-w2cjd                 3/3     Running   1          28m
kube-system   pod/dns-autoscaler-56bf5c7f58-cz2jr    1/1     Running   0          29m
kube-system   pod/kube-proxy-6xmdd                   1/1     Running   0          30m
kube-system   pod/kube-proxy-qq27q                   1/1     Running   0          30m
kube-system   pod/ncloud-kubernetes-f5lxr            1/1     Running   0          49s
kube-system   pod/ncloud-kubernetes-kgt9p            1/1     Running   0          49s
kube-system   pod/nodelocaldns-mkzqz                 1/1     Running   0          29m
kube-system   pod/nodelocaldns-mvc7f                 1/1     Running   0          29m
kube-system   pod/snapshot-controller-0              1/1     Running   0          28m
kube-system   pod/startup-script-jtknz               1/1     Running   0          27m
kube-system   pod/startup-script-zlg28               1/1     Running   0          27m

NAMESPACE     NAME                     TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                  AGE
default       service/kubernetes       ClusterIP   198.19.128.1     <none>        443/TCP                  31m
kube-system   service/coredns          ClusterIP   198.19.128.3     <none>        53/UDP,53/TCP,9153/TCP   29m
kube-system   service/metrics-server   ClusterIP   198.19.128.124   <none>        443/TCP                  28m

NAMESPACE     NAME                               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
kube-system   daemonset.apps/cilium              2         2         2       2            2           <none>                   30m
kube-system   daemonset.apps/cilium-monitor      2         2         2       2            2           <none>                   27m
kube-system   daemonset.apps/csi-nks-node        2         2         2       2            2           <none>                   28m
kube-system   daemonset.apps/kube-proxy          2         2         2       2            2           kubernetes.io/os=linux   31m
kube-system   daemonset.apps/ncloud-kubernetes   2         2         2       2            2           <none>                   27m
kube-system   daemonset.apps/nodelocaldns        2         2         2       2            2           <none>                   29m
kube-system   daemonset.apps/startup-script      2         2         2       2            2           <none>                   27m

NAMESPACE     NAME                              READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/cilium-operator   2/2     2            2           30m
kube-system   deployment.apps/coredns           2/2     2            2           29m
kube-system   deployment.apps/dns-autoscaler    1/1     1            1           29m

NAMESPACE     NAME                                         DESIRED   CURRENT   READY   AGE
kube-system   replicaset.apps/cilium-operator-78f6b5db7c   2         2         2       30m
kube-system   replicaset.apps/coredns-7895d49695           2         2         2       29m
kube-system   replicaset.apps/dns-autoscaler-56bf5c7f58    1         1         1       29m

NAMESPACE     NAME                                   READY   AGE
kube-system   statefulset.apps/csi-nks-controller    1/1     28m
kube-system   statefulset.apps/snapshot-controller   1/1     28m

오늘은 NKS 생성과 사용법에 대해 간단하게 알아보았습니다.

NKS를 잘 사용하기 위해서는 Container Registry를 이용해서 컨테이너 이미지를 관리한다거나 Cloud Insight 서비스를 신청해서 모니터링 하기 등이 있습니다.

이는 DKOS 스터디가 진행하며 조금씩 제 블로그에 포스팅할 예정입니다.


Personal Comments

오늘은 네이버 클라우드에서 쿠버네티스 배포에 대해서만 간단하게 포스팅해보았습니다.

쿠버네티스 서비스를 사용하시기 전 VPC에 익숙하지 않으시다면 네이버 클라우드에서 교육하고 있는 Hands-on Lab을 신청하여 들어보시는 것을 권장드립니다.

네이버 클라우드는 한국어로 된 교육과 서비스로 쉽게 배우고 사용할 수 있다는 점이 큰 장점이라고 생각합니다.

추가로 요즘 회사와 주말 일정으로 포스팅되는 날짜가 일정하진 않지만 한 주에 최소 포스팅 2개를 목표로 꾸준히 작성중이니 참고 부탁드립니다.

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

NCP

2-2. [NCP] 네이버 클라우드에서의 보안 – Server (내부 방화벽을 이용한 GEOIP)

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

오늘 포스팅은 이전 포스팅 주제였던 ACG(Access Control Group)에 이어 서버 내부 방화벽,
그 중에서도 GEOIP에 대해서 작성해보려합니다.

글로벌 사이버테러는 지속적으로 늘어나고 있고 공격 유형도 다양해지고 있습니다.

ACG는 Inbound Rule이 기본 차단이고 추가하는 IP/ACG에 대해서 허용하는 방식입니다.
또한 NACL을 이용한다고 하여도 한 국가가 사용하는 IP 대역을 전부 허용/차단 룰을 추가해주는 것도 힘들 것입니다.

주로 웹 서비스가 대표적인 케이스인데 해외 서비스를 하지 않는 경우 또는 특정 국가에서 서비스를 해야하는데 지속적인 공격으로 지역 기반 차단이 필요한 경우가 있습니다.

물론 Naver Cloud Platform의 Security Monitoring 서비스를 사용한다면 IDS/IPS, WAF, Anti-DDOS 등을 사용할 수 있으나 아직 보안 장비에 투자할 비용이 부족한 사용자에게는 부담스러울 수가 있어 비록 100% 완벽하지 않으나 어느정도 피해를 최소화하기 위해 GeoIP 모듈을 이용하여 내부 방화벽으로 서버를 지역 기반 차단하는 방법을 작성해보겠습니다.


Linux

iptables

Linux에서 지역 기반 차단을 진행해봅시다.
방화벽은 모두가 아는 iptables를 사용할 것입니다.

[Environment]
Naver Cloud Platform : centos-7.8-64

※ 기본 설정 및 설치 😎

[root@manvscloud-dev-pub-kr1 ~]# sestatus 
SELinux status:                 disabled

[root@manvscloud-dev-pub-kr1 ~]# yum install -y iptables*
yum install lrzsz libtool wget patch pcre-devel lua-devel libxml2-devel ncurses-devel zlib zlib-devel libtermcap-devel libc-client-devel bison gcc g++ cpp gcc-c++ curl curl-devel make automake unzip zip xz -y

[root@manvscloud-dev-pub-kr1 ~]# yum install -y "kernel-devel-uname-r == $(uname -r)"

[root@manvscloud-dev-pub-kr1 ~]# yum install -y yum install perl-Text-CSV_XS perl-NetAddr-IP perl-CPAN.noarch

※ Kernel-devel 확인 🕶

kernel-devel이 정상적으로 설치되지 않으면 이후 설치할 xtables 컴파일이 정상적으로 되지않습니다. yum으로 현재 커널 버전에 맞는 kernel-devel이 설치되지 않을 경우 repo를 찾아 커널 버전에 devel을 설치해주어야합니다.

※ xtables 설치 😎

[root@manvscloud-dev-pub-kr1 ~]# cd /usr/local/src
[root@manvscloud-dev-pub-kr1 src]# wget mirror.koreaidc.com/iptables/xtables-addons-2.10.tar.gz

// https://sourceforge.net/projects/xtables-addons/files/Xtables-addons/ ← 접속 시 각 버전별 xtables가 있습니다.

[root@manvscloud-dev-pub-kr1 src]# tar xvfz xtables-addons-2.10.tar.gz
[root@manvscloud-dev-pub-kr1 src]# cd xtables-addons-2.10/
[root@manvscloud-dev-pub-kr1 xtables-addons-2.10]# cat -n mconfig | grep TARPIT
    12	build_TARPIT=m

// build_TRIPIT=m은 redhat에서 지원하지않아 주석처리 해주었습니다.
[root@manvscloud-dev-pub-kr1 xtables-addons-2.10]# sed -i '12s/build_TARPIT=m/#&/' mconfig

(참고로 CentOS6 버전 이용 시 커널 버전이 낮아 xtables 버전 역시 낮춰서 설치하셔야합니다.
1.37버전 설치 권장드리며 mconfig에서 build_RAWNAT=m, build_SYSRQ=m, build_TARPIT=m, build_length2=m 총 4가지를 주석처리 해줘야합니다.)

[root@manvscloud-dev-pub-kr1 xtables-addons-2.10]# ./configure
[root@manvscloud-dev-pub-kr1 xtables-addons-2.10]# make
[root@manvscloud-dev-pub-kr1 xtables-addons-2.10]# make install
[root@manvscloud-dev-pub-kr1 xtables-addons-2.10]# cd geoip

[root@manvscloud-dev-pub-kr1 geoip]# ./00_download_geolite2
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0curl: (6) Could not resolve host: geolite.maxmind.com; Unknown error

00_download_geolite2를 실행해도 되지않기때문에 따로 GeoLite2-Country-CSV를 받아야합니다.
https://maxmind.com/ 에 가입 후 라이센스 발급 및 GeoLite2-Country-CSV.zip 설치가 가능합니다.

// 아래 MaxMind 링크를 추가해두었습니다.
[root@manvscloud-dev-pub-kr1 geoip]# ll | grep GeoLite2
-rw-r--r-- 1 root root 1934768 May 29 08:25 GeoLite2-Country-CSV_20210525.zip

[root@manvscloud-dev-pub-kr1 geoip]# ./10_download_countryinfo
[root@manvscloud-dev-pub-kr1 geoip]# unzip GeoLite2-Country-CSV_20210525.zip
[root@manvscloud-dev-pub-kr1 geoip]# perl -MCPAN -e shell
cpan[1]> install NetAddr::IP
cpan[2]> install Getopt::Long
cpan[3]> quit

[root@manvscloud-dev-pub-kr1 geoip]# cat GeoLite2-Country-CSV_20210525/GeoLite2-Country-Blocks-IPv{4,6}.csv | ./20_convert_geolite2 /tmp/CountryInfo.txt > GeoIP-legacy.csv
[root@manvscloud-dev-pub-kr1 geoip]# ./xt_geoip_build GeoIP-legacy.csv
[root@manvscloud-dev-pub-kr1 geoip]# mkdir -p /usr/share/xt_geoip
[root@manvscloud-dev-pub-kr1 geoip]# cp -a {BE,LE} /usr/share/xt_geoip/
[root@manvscloud-dev-pub-kr1 geoip]# cp -a /etc/sysconfig/iptables /etc/sysconfig/iptables_org

[root@manvscloud-dev-pub-kr1 ~]# systemctl enable iptables
[root@manvscloud-dev-pub-kr1 ~]# systemctl start iptables

/etc/sysconfig/iptables 수정하여 룰셋 적용해서 사용하시면 됩니다.


TIP & Personal Comments and Wrap-up

windows firewall

Windows에서 역시 국가 기반 차단이 가능합니다.

Powershell을 이용한 방화벽 컨트롤 및 IPSec 설정의 방법이 존재하는데 이번 편에서는 따로 다루지 않고 IPsec 편에서 추가적으로 설명하도록 하겠습니다.

또한 Apache와 Nginx 등 소프트웨어단에서 국가 기반 차단을 할 수도 있습니다.
이후 이러한 소프트웨어단에서 국가 기반 차단을 하는 방법도 포스팅할 것입니다.

위 링크는 WHOIS입니다.
서버내에서 공격성 접근 확인 시 해당 IP를 위 사이트에서 검색할 경우 어느 나라의 IP인지 확인이 가능합니다.

국가 기반 차단 시 필요한 국가 코드 및 WHOIS 조회 시 국가코드가 어느 나라인지 확인할 수 있는 국가 코드 조회 사이트도 참고하시면 좋을듯합니다.

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


NCP

2-1. [NCP] 네이버 클라우드에서의 보안 – Server (ACG)

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

“1-1~1-2. [NCP] 네이버 클라우드에서의 보안 – Account 편” 포스팅이 끝나고
“2. [NCP] 네이버 클라우드에서의 보안 – Server 편” 포스팅을 작성하게 되었습니다.

오늘은 네이버 클라우드에서 Server 보안의 첫 번째 ACG(Access Control Group)를 알아봅시다.
ACG는 IP/Port 기반 네트워크 접근 제어 및 관리를 할 수 있는 무료 방화벽 서비스입니다.
Console에서 쉽게 허용된 트래픽만 접근할 수 있도록 설정하여 외부의 침입으로부터 차단해주는데 간단하고 단순하지만 잘 사용한다면 견고한 보안을 보여줄 것입니다.


ACG (Access Control Group)

https://www.ncloud.com/product/networking/vpc

네이버 클라우드에서 ACG는 Classic 환경과 VPC 환경에 조금 차이가 있습니다.
간단하게 표로 만들어보았으니 그림을 통해 차이를 확인해보시기 바랍니다.

Classic – ACG
VPC – ACG

ACG에서는 TCP, UDP, ICMP 프로토콜에 대해 규칙 설정이 가능하며 192.168.0.1(단일), 10.0.1.0/24(대역), 0.0.0.0/0(전체), manvscloud-acg(ACG 이름) 으로 접근소스 지정이 가능합니다. (manvscloud.com과 같이 도메인은 불가능)

VPC 환경에서는 Inbound / Outbound 규칙을 설정할 수 있으며 기본적으로 Inbound는 차단, Outbound는 허용입니다. (Classic은 X)

  • Inbound 규칙 : 서버로 들어오는 트래픽(외부→내부)에 대한 규칙
  • Outbound 규칙 : 서버에서 나가는 트래픽(내부→외부)에 대한 규칙

How to use ACG well

ACG를 어떻게 잘 사용할까요?

VPC 환경을 기준으로 아래와 같이 서버를 생성하여 보여드리겠습니다.

예시로 bastion host 1대, web server 1대, db server 1대를 생성하였습니다.
Bastion host에 대한 ACG는 정말 접속이 필요한 사용자만 접근할 수 있도록 허용하는 방법을 사용하고 추가적인 접근 통제는 VPN 또는 서버 내부에서 사용자 계정을 생성하여 계정 관리 및 탐지를 합니다.

Web Server는 ACG를 어떻게 주면 좋을까요?
Web Server로 SSH 접근하는 IP를 추가해주어야 할 것이고 HTTP, HTTPS 포트도 열어주어야할 것입니다.
저는 ACG 하나에 몰아서 넣기보다 분리해서 사용하며 ACG 생성 시 네이밍도 이후 잘 구분할 수 있도록 만드는 편입니다. (프로젝트명-용도-acg)

manvscloud-admin-acg에는 관리자 접속용 acg입니다.
manvscloud 프로젝트 전체에 접속이 필요한 관리자들에 대한 정책을 추가하여 사용합니다.
동일한 프로젝트의 다른 서버 생성 시에도 해당 acg만 추가해주기만 하면 되어 관리하기도 좋습니다.
또한 manvscloud-web-acg는 manvscloud 프로젝트의 web서버에 대한 acg입니다.
web서버마다 동일하게 필요한 정책을 추가하여 관리합니다. 이후 추가되는 web 서버마다 acg를 추가 생성하지 않고 해당 acg를 추가하여 공통으로 사용합니다.
마지막 하나의 acg는 위 사진에는 추가되어 있지않지만 필요 시에 해당 서버에만 특정적으로 필요로하는 서비스 해당 서버에서만 open되어야하는 정책에대한 acg를 추가하여 관리합니다. (예를 들면 개발자가 특정 웹 서버 FTP 접근이 필요할 경우)

정리하면 제가 ACG를 관리하는 방식은 아래와 같습니다.

  1. admin-acg (프로젝트 공통 관리자 관리 정책 ACG)
  2. web-acg, mysql-acg, was-acg 등 (공통 서비스 관리 정책 ACG)
  3. *-acg (특정 서버에만 적용되어야하는 정책 ACG)

더 좋은 ACG 사용 방법이 있다면 댓글로 의견 부탁드립니다.

위 정책은 웹 서버에 대한 web-acg 입니다.
제가 80포트를 0.0.0.0/0이 아니라 왜 10.0.13.0/24와 10.0.33.0/24 으로 열어두었을까요?

이유는 바로 제가 LB와 연결을 해놓았기때문입니다.
많은 고객분들이 웹 서버와 LB를 함께 사용하십니다.

[root@manvscloud-web-pub-kr2 ~]# tail -f /var/log/httpd/access_log 
10.0.13.11 - - [25/May/2021:07:15:15 +0900] "HEAD /index.html HTTP/1.1" 200 - "-" "-"
10.0.13.11 - - [25/May/2021:07:15:15 +0900] "HEAD /index.html HTTP/1.1" 200 - "-" "-"
10.0.33.11 - - [25/May/2021:07:15:45 +0900] "HEAD /index.html HTTP/1.1" 200 - "-" "-"
10.0.33.11 - - [25/May/2021:07:15:45 +0900] "HEAD /index.html HTTP/1.1" 200 - "-" "-"
10.0.33.10 - - [25/May/2021:07:15:45 +0900] "HEAD /index.html HTTP/1.1" 200 - "-" "-"
10.0.33.10 - - [25/May/2021:07:15:45 +0900] "HEAD /index.html HTTP/1.1" 200 - "-" "-"
10.0.13.10 - - [25/May/2021:07:15:45 +0900] "HEAD /index.html HTTP/1.1" 200 - "-" "-"
10.0.13.10 - - [25/May/2021:07:15:45 +0900] "HEAD /index.html HTTP/1.1" 200 - "-" "-"
10.0.13.11 - - [25/May/2021:07:15:45 +0900] "HEAD /index.html HTTP/1.1" 200 - "-" "-"
10.0.13.11 - - [25/May/2021:07:15:45 +0900] "HEAD /index.html HTTP/1.1" 200 - "-" "-"
Load Balancer

만약 0.0.0.0/0으로 열어두었다면 도메인-LB-웹서버로 통신되는 것 외에도 웹서버 IP를 통해 웹서버로 접근 역시 가능합니다.
물론 웹서버 내에서 IP주소로 접근이 불가능하도록 설정이 가능하지만 방화벽 룰셋은 굳이 접근이 필요하지 않은 부분까지 허용하는 것은 권장하지 않으며 좋은 습관이 아닙니다.

위 ACG와 같이 설정하게되면 LB로는 접속 가능하지만 웹서버 IP로는 다이렉트로 접속이 불가능하게 됩니다.

이제 예시 중 DB Server에 대한 ACG 관리를 보겠습니다.

DB 서버는 주로 bastion host와 DB 연동이 필요한 서버에 대한 허용 정책을 설정하게되는데
아래와같이 ACG 이름을 이용하여 설정할 수 있습니다.

bastion-host Server와 연결된 manvscloud-bastion-acg를 DB Server ACG에 접근 포트 허용을 해주게된다면 manvscloud-bastion-acg와 연결된 서버들은 DB Server로 접근을 할 수 있게되는 것입니다.

추가 예시로 Web Server 전체가 DB와 연결되어야할 경우 ACG를 넣어줄 수 있으며
“나는 모든 웹 서버와 모든 DB 서버가 연결되지 않아 보안상 따로 따로 지정을 해줘야한다”라고 한다면 특정 서버에만 적용되어야하는 정책 ACG를 추가하여 연결되어야할 서버 IP만 허용해주는 방법이 있습니다.


Personal Comments and Wrap-up

지금까지 쉽고 간단한 ACG(Access Control Group)에 대해 알아보았습니다.
많은 사용자들이 귀차니즘으로 인해 ACG 관리가 잘 되지않고 있습니다.
원격 접속 포트, 쉘 접근 포트 등 중요한 포트를 0.0.0.0/0(전체)로 열어두는 사용자들을 생각보다 많이보게되고 또 보안상 위험을 알려도 아무 일 없을 거라며 넘어가버리는 분들 역시 많았습니다.
(귀찮아서 내버려뒀을 때 편한 감정과 공격받아 데이터 손실 후 감정은 많이 다릅니다…)

제발 막아주세요😥

다음 포스팅은 “2-1. [NCP] 네이버 클라우드에서의 보안 – SERVER”에 이어
“2-2. [NCP] 네이버 클라우드에서의 보안 – ACCOUNT” 내용은 IPSec VPN과 SSL VPN에 대해서 작성하려고 했었는데 ACG에 대한 내용에 이어 서버 내부 방화벽 활용 방법을 먼저 포스팅하려고 합니다.

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