npm install iptables.service --> iptables.service 설치
systemctl start iptables --> iptables start
systemctl status iptables

정상적으로 iptables 실행이 되었다. ✔ 이제부터 포트포워딩 설정을 시작해보자!!

net.ipv4.ip_forward = 0 -> 1 로 변경

포트포워딩을 허용하겠다 -> 이런 의미??

❗ eth0 인터페이스를 통해 10021으로 목적지 주소로(즉, 내 WEB IP로 ) 22번 포트로 접속하겠다.

service iptables restart - 서비스 재시작

telnet으로 WEB으로 접속 확인!!

여기까지 CMS -> WEB으로 포트포워딩이 성공되었다.

그럼, WEB 설치 해서 홈페이지를 열어보자!!

1. WEB 패키지 설치

✅ PCRE ( Perl Compatible Regular Expressions) ✅ Httpd ✅ apr ( APache Portable Runtime) ✅ apr-util

C 및 C++ Compiler 설치 XML parser 라이브러리 설치

yum install –y gcc-c++ prce-devel expat-devel

PCRE 설치

wget https://sourceforge.net/projects/pcre/files/pcre/8.45/pcre-8.45.tar.gz/download -- pcre 설치
tar xvfz download -- 압축해제

Apache 설치 & 압축해제

wget https://dlcdn.apache.org//httpd/httpd-2.4.52.tar.gz -- apache 설치
tar xvfz httpd-2.4.52.tar.gz --압축해제

APR 설치 & 압축해제

wget https://mirror.navercorp.com/apache//apr/apr-1.7.0.tar.gz -- apr 설치
tar xvfz apr-1.7.0.tar.gz -- 압축해제

APR-util 설치 & 압축해제

wget https://mirror.navercorp.com/apache//apr/apr-util-1.6.1.tar.gz -- apr-util 설치
tar xvfz apr-util-1.6.1.tar.gz --압축해제

필자는 압축을 푼 4개 디렉터리를 /usr/local로 이동 할 것이다.

mv apr-1.7.0 apr-util-1.6.1 httpd-2.4.52 pcre-8.45 /usr/local/

APR 설치

./configure --prefix=/usr/local/src/apr-1.7.0 

make && make install

APR-Util 설치

./configure --prefix=/usr/local/src/apr-util-1.6.1 --with-apr=/usr/local/src/apr-1.7.0

make && make install

pcre 설치

./configure --prefix=/usr/local/src/pcre-8.45 \
--with-apr-util=/usr/local/src/apr-util-1.6.1 \
--with-apr=/usr/local/src/apr-1.7.0

make && make install

httpd 설치

./configure --prefix=/usr/local/apache2.4.52 \
--enable-modules=most --enable-mods-shared=all --enable-so \
--with-apr=/usr/local/src/apr-1.7.0 \
--with-apr-util=/usr/local/src/apr-util-1.6.1 \
--with-pcre=/usr/local/src/pcre-8.45

make && make install

서버 설정

vim /usr/local/apache2.4/conf/httpd.conf

Require all granted: 무조건 허용 Require all denied: 무조건 금지 Require ip xx.xx.xx xx.xx.xx.xx : 특정 아이피만 접근 허용.

Apache 실행

cd /usr/local/apache2.4.52
./bin/apachectl start

필자는 포트포워딩을 이용하여 10022으로 80번 포트로 접속하였다. 결과적으로, it works! 화면이 뜬 모습을 볼 수 있다.

2. WAS 인터넷 환경 구성하기

Tomcat 설치 하기 전, WAS는 Private 환경이기 때문에, 인터넷 환경이 안된다.

✅ "Squid"는 프록시 서버 프로그램

프록시 서버는 인터넷 사용자들이 웹사이트에 접속할 때 요청(request)을 받아서 대신 해당 웹사이트로 요청(request)을 보내주는 중개자 역할을 합니다. Squid 서비스는 이러한 프록시 서버 기능을 제공합니다.

그 전에,** Squid 서비스를 이용해서 **WAS 서버에 인터넷 환경을 구성해보겠다.

CMS Server

yum -y install squid -- Squid 설치
systemctl start squid -- Squid 실행

vim /etc/squid/squid.conf
http_access allow localhost

systemctl restart squid

WAS Server

vim /etc/yum.conf
proxy=http:// CMS 서버 IP : 3128

vim /etc/wgetrc
http_proxy=CMS 서버 IP : 3128
https_proxy=CMS 서버 IP : 3128

성공적으로 WAS에서 인터넷 환경이 구성되었다.

3. Tomcat 설치

그럼 이제, WAS Tomcat 설치를 진행해보겠다.

설치 진행 전, java 설치

yum list java*jdk-devel -- java 설치 진행
yum install java-1.8.0-openjdk-devel.x86_64  -- java-1.8.0 버전을 설치
java --version -- 자바 버전 확인

readlink -f /bin/javac -- java 원본 파일 위치 확인

JAVA_HOME이 될 경로

/usr/lib/jvm/java-11-openjdk-11.0.11.0.9-1.el7_9.x86_64/jre

환경변수 설정

vi /etc/profile

export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-11.0.11.0.9-1.el7_9.x86_64/jre

설정 후 명령어 입력

source /etc/profile -- 설정
echo $JAVA_HOME -- 결과 확인

Tomcat 설치

wget http://archive.apache.org/dist/tomcat/tomcat-8/v8.5.27/bin/apache-tomcat-8.5.27.tar.gz
tar zxvf apache-tomcat-8.5.27.tar.gz --압축 해제

압축 해제한 톰캣을 /usr/local/ 경로로 이동

mv apache-tomcat-8.5.27 /usr/local/

환경변수 등록

export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b08-1.el7_9.x86_64/jre
export CATALINA_HOME=/usr/local/apache-tomcat-8.5.87
export CLASSPATH=$JAVA_HOME/jre/lib:$JAVA_HOME/lib/tools.jar:$CATALINA_HOME/lib-jsp-api.jar:$CATALINA_HOME/lib/servlet-api.jar
export PATH=$PATH:$JAVA_HOME/bin:/bin:/sbin
export JAVA_HOME PATH CLASSPATH CATALINA_HOME
source /etc/profile

server.xml 설정

vi /usr/local/apache-tomcat-8.5.87/conf/server.xml
<Connector port="8080" protocol="HTTP/1.1"
           connectionTimeout="20000"
           redirectPort="8443"
           URIEncoding="UTF-8" />

Tomcat 실행

/usr/local/apache-tomcat-8.5.87/bin/startup.sh

8080포트가 열렸는지 확인

netstat -ntl

WAS Tomcat 실행 모습

성공적으로 냥이가 떴다.

오늘은, CMS 서버에서 WEB, WAS 포트포워딩, WEB 패키지 설치와 WAS 패키지 설치에 대해서 진행해보았다. CMS에서 포트포워딩을 하니 서버 관리도 되고, 편리했다. 이렇게 좋은 줄 알았으면, 진작에 해볼걸.. 포트포워딩 서비스와 squid 서비스까지 다양한 서비스를 알아가니 내 자신이 스킬업되는 기분이다.😁

다음에는, WEB과 WAS 연동에 대해서 실습을 진행해보겠다.

3 Tire

일반적으로 소프트웨어 시스템이나 웹 애플리케이션 등에서 사용되는 용어로, 세 개의 계층으로 이루어진 아키텍처를 의미합니다.

일반적으로 3 tiers 아키텍처는 다음과 같이 구성됩니다:

1️⃣ 프레젠테이션 계층 (Presentation Tier):

사용자 인터페이스(UI)와 관련된 부분으로, 사용자가 시스템과 상호작용하는 부분입니다. 일반적으로 웹 브라우저나 애플리케이션 클라이언트 등이 해당됩니다.

2️⃣ 비즈니스 계층 (Business Tier):

비즈니스 로직을 처리하는 부분으로, 데이터 처리, 알고리즘, 데이터베이스 연결, 보안 등의 기능을 수행합니다. 일반적으로 서버 애플리케이션이 해당됩니다.

3️⃣ 데이터 계층 (Data Tier):

데이터를 저장하고 관리하는 부분으로, 데이터베이스나 파일 시스템 등의 저장소를 포함합니다.

이러한 3계층 구조는 각 계층이 독립적으로 작동하여, 시스템의 확장성, 유지보수성, 보안성 등을 향상시키는데 도움을 줍니다. 또한 각 계층은 다른 계층과 인터페이스를 통해 서로 연결되어 작동하므로, 시스템 내부의 변경이나 업그레이드를 용이하게 합니다. 역시 인공지능 챗봇이 짱이다. 챗봇이 다 알려준다.

3 Tire 구성도

이건 챗봇이 안 짰고, 필자가 짠 3 Tire 구성도이다. 아직 부족해서 잘 못 짰지만, 이런 구도이다. 다음 장에 진행한 실습을 보여드리겠다.

mod_jk 란?

아파치와 톰캣을 연동하기 위한 모듈로써 AJP 프로토콜을 이용하여 아파치에 들어온 요청 중 톰캣이 처리할 요청을 AJP 포트(일반적으로 8009)를 통해 톰캣에 전달하고 그에 대한 응답을 받는 역할을 수행한다.

아파치와 톰캣을 연동하는 방법은 mod_jk(tomcat connector)를 이용한 방법, mod_proxy를 이용한 방법, mod_proxy_ajp를 이용한 방법 크게 3가지가 있다. 그 중에 mod_jk 이 방식을 이용하여 연동하겠다.

Apache와 Tomcat을 연동하기 위해서는 Apache, Tomcat가 필수적으로 필요하다.

첫번쨰로, Apache를 설치해보겠다.

yum install -y httpd
systemctl enable httpd -- 서비스 등록
systemctl start httpd  -- 서비스 시작

Apache port 80 이다. 필자는 포트포워딩을 해서 공인 포트로 접속하였다. 또한, 클라우드 서비스를 이용해서 서버에 접속했기 때문에 방화벽에 대해서 설정하고 왔다. Apache 설치 끝!!

두번째로 Tomcat 에 대해서 설치하겠다. Tomcat을 설치하기 위해서는 JDK가 필수적으로 필요하다. JDK 설치는 쉬우기 떄문에, 설치과정을 요약하겠다. JDK 설치

yum list java*jdk-devel
java-1.8.0-openjdk-devel.x86_64 --최신버전으로 해도 된다.
yum install -y java-1.8.0-openjdk-devel.x86_6
java -version

*JDK 설치 끝 *

Tomcat 설치

1. Tomcat 사이트에서 링크 복사

wget http://archive.apache.org/dist/tomcat/tomcat-10/v10.0.6/bin/apache-tomcat-10.0.6.tar.gz

최신 버전으로 해도 된다.

2. 압축 풀기

tar zxvf apache-tomcat-10.0.6.tar.gz

3. 톰캣 설치한 경로 👉 bin 👉 ./startup.sh 입력

4. Tomcat 실행

5. Tomcat 실행 페이지

Tomcat port 8080 이다. 필자는 포트포워딩을 해서 공인 포트로 접속하였다. Apache 와 Tomcat 설치가 끝났다. 마찬가지로 방화벽도 확인!! 이제 연동만 남았다. 가자고 ~

WEB / WAS 연동

1. tomcat-connector 다운

wget http://ftp.tsukuba.wide.ad.jp/software/apache/tomcat/tomcat-connectors/jk/tomcat-connectors-1.2.48-src.tar.gz

2. 압축 풀기

tar zxvf tomcat-connectors-1.2.48-src.tar.gz

3. gcc, gcc-c++, httpd-devel 설치 (연동하는데 필요한 라이브러리라고 생각하면 된다.)

yum -y install gcc gcc-c++ httpd-devel

4. tomcat-connector 설치한 경로 👉 native

5. ./configure --with-apxs=/usr/bin/apxs' 입력

./configure --with-apxs=/usr/bin/apxs

6. make

make

7.make install

make install

8. Apache /conf'에서 'vi httpd.conf' (맨 아래에 구문 추가)

LoadModule jk_module modules/mod_jk.so
<IfModule mod_jk.c>
    JkWorkersFile conf/workers.properties
    JkShmFile run/mod_jk.shm
    JkLogFile logs/mod_jk.log
    JkLogLevel info
    JkLogStampFormat "[%y %m %d %H:%M:%S] "
</IfModule>

<VirtualHost *:80>
    JkMount /* tomcat
    ServerName localhost
</VirtualHost>

9. Apache /conf에서 'vi workers.properties'

worker.list=tomcat
worker.tomcat.port=8009
worker.tomcat.host=localhost
worker.tomcat.type=ajp13
worker.tomcat.lbfactor=1

10. Tomcat/conf'에서 'vi server.xml'

<!--
<Connector port="8080 protocol="HTTP/1.1"
                    ========
                    ========
                    redirectPort="8443" />
-->
이 부분 주석처리 꼭 해야함
<Connector protocol="AJP/1.3"
   address="0.0.0.0"
   secretRequired="false"
   port="8009"
   redirectPort="8443"/>

10. 'Tomcat/bin에서 './startup.sh' 입력

./startup.sh

11. Apache 재 가동

systemctl restart httpd

12. 연동 완료 !!!

80번 포트를 입력했을 떄, 톰캣 페이지가 나오면 연동이 된 것이다. WEB / WAS 연동이 끝이 났다. 하면서 오류 투성이었고, 잘 안 되어서 서버를 몇 개나 삭제했는지 모르겠다. 그래도 IT 지식인들의 도움으로 해결 되었고, 다른 사람들 블로그를 보면서 공부를 많이 한 것 같다. 난 아직 그분들에 비해서...아직 우물안의 개구리다ㅎㅎㅎㅎ 이분들이 있어 공부자료가 많고 다양해서 고맙다. 더 열심히 하는 내가 되자!!!

참고 : https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=tawoo0&logNo=221587063882

WEB / WAS 란?

Web Server

(출처 : https://story.pxd.co.kr/)

WAS

(출처 : https://story.pxd.co.kr/)

간단히 정리만 하겠다.

웹 서버란 HTTP 프로토콜을 기반으로 클라이언트가 웹 브라우저에서 어떠한 요청을 하면 그 요청을 받아 정적 컨텐츠를 제공하는 서버이다. ✔ 정적 컨텐츠란 단순 HTML 문서, CSS, 이미지, 파일 등 즉시 응답 가능한 컨텐츠이다.

동작 구조 : 웹 서버가 정적 컨텐츠가 아닌 동적 컨텐츠를 요청받으면 WAS에게 해당 요청을 넘겨주고, WAS에서 처리한 결과를 클라이언트에게 전달하는 역할도 해준다.

이러한 웹 서버에는 Apache, NginX 등이 있다.

WAS란 DB 조회 혹은 다양한 로직 처리를 요구하는 동적 컨텐츠를 제공하기 위해 만들어진 Application 서버이다. HTTP 프로토콜을 기반으로 사용자 컴퓨터나 장치에 애플리케이션을 수행해주는 미들웨어로서, 주로 데이터베이스 서버와 같이 수행된다.

WAS는 JSP, Servlet 구동환경을 제공해주기 때문에 서블릿 컨테이너 혹은 웹 컨테이너로 불린다.

사용적인 대표 예시 : Tomcat, JBoss, WebSphere

차이점 : 웹 서버는 정적인 데이터를 처리하는 서버입니다. WAS 만을 이용할 때보다 빠르고 안정적으로 기능을 수행하고, WAS는 동적인 데이터를 위주로 처리하는 서버입니다. DB와 연결되어 사용자와 데이터를 주고받고, 조작인 필요한 경우 WAS를 활용합니다.

따라서, 단순한 정적 컨텐츠는 웹 서버에게 맡기고, 기능을 분리해 서버 부하를 방지해야 한다.

이러한, 개념을 바탕으로 왜 Web 와 was를 연동해서 써야하는지 알꺼 같다. 이번 포스팅을 Web, was의 기능과 개념을 간단하게 적어보았고, 다음 포스팅에는 Web, WAS 연동에 대해서 실습을 해 보겠다.

홧이팅 🔥🔥🔥

쿠버네티스 ( Kubernetes )

개념

쿠버네티스 (k8s, Kubernetes, 큐브, kube)는 컨테이너화된 애플리케이션을 배포, 관리, 확장할 때 수반되는 다수의 수동 프로세스를 자동화하는 오픈소스 컨테이너 오케스트레이션 플랫폼이다.

쿠버네티스 필요성 및 의의

예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야 한다. 이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까?

이러한 문제를 쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공한다. 애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공한다.

쿠버네티스의 장점

⭕ 서비스 디스커버리와 로드 밸런싱 쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있다.

⭕ 스토리지 오케스트레이션 쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재

⭕ 자동화된 롤아웃과 롤백 쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경

⭕ 자동화된 빈 패킹(bin packing) 컨테이너화된 작업을 실행하는데 사용할 수 있는 쿠버네티스 클러스터 노드 제공, 각 컨테이너가 필요로 하는 CPU와 메모리(RAM)를 쿠버네티스에게 지시

⭕ *자동화된 복구(self-healing) * 쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.

⭕ 시크릿과 구성 관리 쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리

개념과 장점을 보았을 때, 가장 완벽한 시스템이다. 쿠버네티스를 한번 이용해보고 싶다는 생각이 든다. 얼마나 편리한 시스템이 아닌가.. 역시 대세인 이유가 있다. 실습하러 고고~

Cloud 서버는 가상화 소프트웨어(하이퍼바이저라고 함)를 사용하여 물리적 서버를 여러 가상 서버로 나눈다. 하이퍼바이저는 서버의 처리 기능을 추출하고 함께 풀을 만들어 가상 서버를 만든다.

말 그대로 Cloud 서버는 제공 기능을 실행하는데 필요한 소프트웨어를 이용하여 컴퓨팅 제공 모델을 제공한다.

Ubuntu에 대해 설명하겠다.

Ubuntu

📍 Ubuntu

1.다양한 Linux 배포판이 있다. 2.Ubuntu Server는 클라우드 및 서버에 적합하고 Ubuntu Core는 IoT (Internet of Things) 기반 장치를 개발하는 데 적합하다. 3.우분투는 또한 Linux 배포판이다. 4.우분투에는 그래픽 사용자 인터페이스 (GUI)와 명령 행 인터페이스 (CLI)가 있다. 5.우분투 데스크톱 버전은 개인용 컴퓨터에 적합하다. 6.Ubuntu는 보안으로 인해 사용자들 사이에서도 인기가 있다.

장점를 요약해서 작성했지만, 사실은 더 많은 장점들이 있다. 🔥 사실 서버는 명령어가 제일 중요하다.

📋알아두면 편리한 명령어 목록📋

gksu nautilus: ALT+F2에서 입력, 관리자 권한으로 탐색기 열기. im-switch -c: 터미널에서 입력, 한글 입력기 변경, 주로 nabi를 사용. gconf-editor: ALT+F2에서 입력, GNOME의 전반적인 환경설정. 레지스트리 편집기 (sudo) apt-get: 터미널에서 입력, 터미널에서 프로그램을 설치(install)하거나 제거(remove)하거나 설치파일을 깔끔하게 지울 때. (sudo) chmod: 파일의 실행 권한을 설정하는 명령어 (sudo) chown: 파일의 소유권을 설정하는 명령어로 sudo 계정명(UID). 그룹명(GID) '파일 또는 디렉터리' 형태로 사용 (sudo) ln -s: 특정 파일이나 폴더에 대한 심볼릭 링크를 거는 명령어, 윈도우의 바로가기 아이콘 생성 기능 fsck: 파티션 복구 명령어다. 우분투를 강제종료하면 오류를 뿜는데 fsck -fv -y <파티션> 형식으로 사용하는 것을 추천

서버는 명령어의 이해와 네트워크도 잘 이용해야 한다. 그래서 서버 분야도 공부를 해야 한다. 오늘은, 클라우드의 서버 우분투에 대해서 공부를 했다.

항상 공부하는 내가 되자 🔥🔥

1. NHN Cloud 홈페이지에 들어가면 console 버튼이 있다. 👉 눌러보자!

2. 이렇게 보면 콘솔 옆에 조직을 만들고, 그 조직 안에 팀을 만들 수가 있다.

⭕ 장점: 조직을 만들고 팀프로젝트 할떄 매우 유용하다. 그룹성이 있기 떄문이다. 내 생각

3. 다양한 서비스가 있다.

Network 목록을 보면 다양한 Network에 관한 서비스가 있다.

오늘은 VPC에 대해 설명하겠다. 말 나온 김에, NHN VPC 구성도를 설계해보았다. 미흡하지만, 잘 봐주세요

여기서 Public Subnet & Private Subnet 이란?

VPC내에는 보통 Public Subnet과 Private Subnet으로 구성되어 있다.

Public Subnet: Public Subnet의 특징은 Internet Gateway, ELB, 그리고 Public IP/Elastic IP를 가진 인스턴스를 내부에 가지고 있다. 특히, Public Subnet 내에 있는 Nat Instance를 통하여 Private Subnet내에 있는 instances이 인터넷이 가능하게 한다.

Private Subnet: 기본적으로 외부와 차단되어 있다. Private Subnet내의 인스턴스들은 private ip만을 가지고 있으며 internet inbound/outbound가 불가능 하고 오직 다른 서브넷과의 연결만이 가능하다.

Routing table: VPC에 있는 각 서브넷을 라우팅 테이블과 연결해야 한다. 인터넷 게이트웨이, NAT Gateway 및 VPC의 라우팅을 보여준다.

Internet Gateway: 인터넷 게이트웨이는 수평 확장되고 가용성이 높은 중복 VPC 구성 요소로, VPC와 인터넷 간에 통신할 수 있게 해준다.

서브넷이 인터넷 게이트웨이로 향하는 라우팅이 있는 라우팅 테이블과 연결되는 경우, 이를 퍼블릭 서브넷이라고 합니다. 서브넷이 인터넷 게이트웨이로 향하는 라우팅이 없는 라우팅 테이블과 연결되는 경우 이를 프라이빗 서브넷 이라고 한다.

즉 , 그리고 프라이빗 서브넷은 NAT GATEWAY를 통해 인터넷 게이트웨이로 흐르기 떄문에 인터넷이 된다.

📍 프라이빗의 서브넷은 라우팅 테이블에 인터넷 게이트웨이에 대한 경로가 없기 때문에 프라이빗 서브넷에 해당합니다.

NAT gateway : 프라이빗 서브넷의 인스턴스가 VPC 외부의 서비스에 연결할 수 있지만 외부 서비스에서 이러한 인스턴스와의 연결을 시작할 수 없도록 NAT 게이트웨이를 사용할 수 있다.

즉, 외부 서비스에서 프라이빗 서브넷의 인스턴스로 접근할 수 없게 하되, 프라이빗 서브넷의 인스턴스에서는 외부 서비스로 접근할 수 있게 해주는 서비스이다.

이렇게 해서 vpc 설계가 끝났다. 설명도 정리되고, 나한테는 또 공부할 수 있는 기회였다. 서비스를 하나씩 익혀보면서, 실습에 들어가야겠다.

오늘도 공부하는 내가 되었다. 내일도 공부하는 내가 되야지 🔥🔥🔥

참고한 자료: https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/VPC_Internet_Gateway.html https://kimjingo.tistory.com/180

앞으로, 클라우드 시장에 스타트를 할 예정이니, 클라우드에 대한 이해라고 생각하면서 블로그를 작성해보겠다.

NHN 클라우드?

NHN Cloud는 오픈스택 기반 클라우드 서비스로 유연한 클라우드 인프라를 제공한다. 개발에 전념할 수 있도록 편리한 인프라와 플랫폼을 제공하는 것은 물론 합리적인 비용으로 서비스를 이용할 수 있다.

웹 브라우저상에서 간단한 클릭만으로 서비스를 사용할 수 있어 누구나 쉽게 사용할 수 있는 클라우드 서비스로 평가받고 있다.

또한 판교에 제1데이터센터(NHN Cloud Center 1, NCC1)를 두고 있으며, 김해와 광주에 신규 데이터센터를 준비 중이다.

나무위키 참조 : https://namu.wiki/w/NHN%20Cloud

NHN의 강점으로는

✔ 다양한 서비스 구성 ✔ 플랫폼 중심 클라우드 ✔ 합리적인 가격 ✔ 강력한 기술 지원 ✔ 글로벌 클라우드

이렇게 5가지가 있다. 그 중에서 눈에 띄었던 강점으로는 기업이 클라우드에서 쉽게 개발할 수 있는 생태계이라는 점이다. 많은 기업들이 온프레미스에서 클라우드로 넘어가는 추세이다. 그래서 기업들은 클라우드 서비스가 필요한 시점인데, NHN 클라우드의 이러한 강점이 행정*공공기관 클라우드 점유율 47%라는 결과를 초래하였다.

아, 그리고 NHN 클라우드의 좋은 점이 NHN cloud 교육 센터가 있다는 점이다. NHN Cloud의 전문가가 온/오프라인으로 교육 세션을 진행하며 클라우드가 처음인 사용자는 물론 사전에 참가 신청하면 무료로 교육에 참가할 수 있다.

선착순이다. 배워보고 싶은 자는 얼른 신청하길 바란다.🔥🔥

👉👉 https://www.nhncloud.com/kr/edu

NHN이 가장 자랑하는 점은 토스트 클라우드가 ‘오픈스택’ 기반이라는 점이다. 오픈스택은 오픈소스 클라우드 운영체제다. 서버, 스토리지, 네트워크 등 자원을 할당하고 관리하는 역할을 한다. 오픈스택은 전 세계에서 가장 유명한 클라우드 플랫폼이지만, 주로 프라이빗 클라우드 구축에 활용된다.

또한, TOAST가 페이코(금융), 고도몰(쇼핑), 한게임(게임) 등 다양한 IT 서비스 경험을 통해 검증된 만큼, 금융과 쇼핑 분야를 중심으로 한 엔터프라이즈 시장에서 충분히 선택 받을 수 있을 것”이라고 말했다.

기사 참조 : https://byline.network/2019/01/22-36/

정말로, NHN 클라우드가 이렇게나 좋은 서비스를 제공하는 지 몰랐다. 나는 우물안의 개구리가 아닌 올챙이다...

그리고, NHN 클라우드에 들어가보면, 생각보다 많은 서비스가 있어 놀라웠다. 서비스를 차차 익혀가면서 한 번 실습을 해봐야겠다. 내일도 공부하는 내가 되자!!!!!

구성도

허접하지만 이해해주셨으면 좋겠다..

간단하게 설명하자면, Github에 소스 코드가 푸쉬되면 자동으로 배포하도록 구성하였으며, 그림과 같은 형태로 진행된다.

1. 개발자가 깃 허브에 코드를 푸쉬 👉 CodePipeline에서 인식
2. 소스 코드를 Code Build에서 빌드 한 뒤, 아티팩트를 s3에 저장
3. Deploy에서 배포 준비
4. 준비가 완료되면 Elastic Beanstalk으로 배포

이렇게 순서대로 진행된다.

실습으로 바로 넘어가겠다.

Elastic Beanstalk

JAVA, PHP , Node.js 같은 친숙한 서버에서 개발된 웹 애플리케이션 및 서비스를 간편하게 배포하고 조정할 수 있는 서비스이다.

말 그대로 개발자에게 굉장히 편리한 서비스이다. AWS에 기초만 있어도 사용 할 수 있다는 장점이 있다.

코드를 업로드 하기만 하면, 로드 밸런싱, 오토 스케일링, 모니터링 , 배포를 자동으로 처리하도록 구성 할 수 있다.

Elastic Beanstalk 생성 👉 https://yatyat2.tistory.com/59

CodeBuild 생성

첫번째로, CodeBuild 프로젝트를 생성하겠다. 필자는 GitHub를 연동하였기 때문에 GitHub 프로젝트를 사용할 예정이다.

환경 이미지 중에서는 관리형 이미지와 사용자 지정 이미지가 있다. 만약, Docker를 사용한다고 하면 사용자 지정 이미지를 사용하면 된다. 필자는 관리형 이미지를 사용할 것이다.

✔ Buildspec 편집 YAML 형식의 빌드 명령 및 관련 설정의 모음이다. CodeBuild 은 빌드를 실행하는 데 사용된다. 소스 코드의 일부로 buildspec을 포함하거나, 빌드 프로젝트를 생성할 때 buildspec을 정의할 수 있다.

필자는 Node.js 빌드해야 하기 떄문에, 사전에 Node, npm를 설치하고 빌드작업을 했다.

참고: https://docs.aws.amazon.com/ko_kr/sdk-for-javascript/v2/developer-guide/setting-up-node-on-ec2-instance.html

phases:
    install:
      commands:
         - npm install
  build:
    commands:
      - npm i --save

Buildspec 소소한 설명 📍

생성이 ✔ 완료되었다.

빌드 시작을 누르자!! 고맙게도 성공함이 떴다.

CodePipeline 생성

codepipeline은 GitHub에 변경된 코드가 푸시되면 감지하고, codebuild를 통해 소스 코드를 빌드 한 뒤 , Elastic Beanstalk로 배포를 실행하는 단계로 통로 같은 역할은 한다.

CodePipeline 검색창에 입력한다. 파이프라인 설정에서 이름을 입력하고, 새 서비스 역할은 클릭한다. 🌟 아티팩트 필자는 아티팩트 떄문에 삽질을 많이 했다..

GitHub에 연결

연결 준비 완료 👉 리포지토리 👉 브랜치 이름

빌드 스테이지 추가

아까 만들었던 빌드 프로젝트를 등록하면 된다.

Elastic Beanstalk으로 배포할 것이다.

Source ✔ Build ✔ Deploy ✔

모든 작업이 완료되었다.

아래 그림과 같이 Elastic Beanstalk 구성으로 이동하면 URL이 바뀐 모습을 볼 수 있을 것이다. URL을 클릭하면 프로젝트의 메인화면이 나온다.

📍 참고: 처음에 포트번호 3000으로 했을 때 bad request라는 500의 nginx 에러 발생!! 포트 번호는 8080으로 해주어야 한다.

프록시 서버 구성 : https://docs.aws.amazon.com/ko_kr/elasticbeanstalk/latest/dg/nodejs-platform-proxy.html

자동 배포 환경 완료 ✔

오늘은 AWS CI/CD 환경에 대해 구축을 해보았다. AWS 인프라 이용해야 할 경우나 GitHub 이외의 다른 리포지토리를 이용 할 경우, 편리성과 유용성이 보장되는 방법이다. AWS CodePipeline은 많은 툴을 통해 빌드를 하고, 배포할지에 대해서 서비스가 편리했다. Codedeploy 서비스 같은 경우에는 배포를 하기 위해서 AWS cli 환경 세팅을 위한 IAM 있어야 해서 처음 하는 사람한테는 어려웠다. 필자가 Codedeploy 서비스 이용해보았다. 물론 삽질은 어마무시하게 했다. 배포 서비스는 배포 할 수 있는 옵션이 많았고, 각종 글마다 다르게 소개되는 옵션들이 많다 보니 오래 걸렸다. S3 저장소를 이용해서 작업도 해봤고, AWS Codedeploy 이용해서 작업도 해봤다. 정리를 얼른 해야겠다.

EC2 : https://velog.io/@dev_96/AWS-AWS-EC2 참고하자!

일단, 인스턴스에 보안그룹 SSH/HTTP 접속 허용을 해야하니 주의하자.

1. EC2 SSH 접속

root 권한으로 작업하는게 좋다.

2. apache2 설치

웹 서버 엔진에는 apache2, Nginx *등 종류가 다양하다. 우리는 오늘 *apache2에 대해 이용할 예정이다. 2.1 yum을 업데이트 해준다.

yum update -y

2.2 apache2 설치

yum install -y httpd

3. apache2 실행

systemctl start httpd
systemctl status httpd

4. index.html 만들기

cd /var/www/html
vi index.html 

화면과 같이 입력

5. 웹 페이지 실행

화면과 같이** ip 주소를 입력**하면 웹 페이지가 실행된다.

오늘은 머리 좀 식힐 겸, 간단한 웹 페이지 실행을 해보았다. 처음 웹 페이지를 실행 할 떄, 신기했었던 적이 엊그제 같은데... 이제는 사이드 프로젝트까지 할 줄이야.. 차근차근 성장했다. 더 열심히 하자!!

✔ VPC 이란?

VPC란 Virtual Private Cloud(VPC)의 약자로 데이터 센터에서 운영하는 기존 네트워크와 아주 유사한 가상 네트워크이다.

따라서, AWS VPC란 AWS 계정 전용 가상 네트워크이다. VPC는 AWS 클라우드에서 다른 가상 네트워크와 논리적으로 분리되어 있다. VPC의 IP 주소 범위를 지정하고 서브넷과 게이트웨이를 추가하고 보안 그룹을 연결할 수 있다.

오늘은 바로 실습에 들어가겠다.

1. AWS 네트워킹 및 콘텐츠 전송으로 들어가면, 맨 아래에 VPC가 있다. VPC를 ✔ 클릭

2. VPC 대시보드에 들어가보면 VPC가 있다. VPC 생성 ✔ 클릭

3. VPC 설정

VPC 설정에 들어가보면, 이름 태그, IPv4 CIDR 블록, IPv4 CIDR 설정이 있다. ⭕ CIDR는** 네트워크 클래스**를 대체하는 주소 범위다.

4. VPC 생성

5. 생성 완료

VPC를 만들었다. 이제 서브넷,라우팅 테이블 설정과 외부 통신을 위해 인터넷 게이트웨이도 설정해줘야 한다.

서브넷 👉 라우팅테이블 👉 인터넷 게이트웨이

6. 서브넷 생성

프로젝트를 하면서 서브넷을 많이 생성하였다. 정리하는 겸 서브넷을 또 생성해보겠다. 서브넷 생성 ✔클릭

6-1. 서브넷 생성 -1

아까 만든 VPC 선택

VPC 선택 한 뒤, 밑에 서브넷 생성 칸이 나온다. 서브넷 이름과 가용 영역, IPv4 CIDR 블록을 설정한다. 서브넷 생성 완료 ✔ 이제 서브넷을 생성했으니, 라우팅 테이블을 설정할 차례다.

7. 라우팅 테이블 생성

라우팅 테이블 생성 클릭 ✔

7-1 라우팅 테이블 생성 -1

이름과 아까 만든 VPC 선택을 한다. 라우팅 테이블 설정 완료 *✔ 이번에 *인터넷 게이트웨이를 설정하겠다.

8. 인터넷 게이트웨이 생성

인터넷 게이트웨이 생성 클릭✔ 이름만 설정하면 생성이 된다.

📍 주의할 점: 내가 방금 만든 인터넷 게이트웨이를 보면 상태가 Detached라고 되어 있는데, 방금 만든 인터넷 게이트웨이를 Attached 상태로 바꿔야 한다.

Detached 👉 Attached

인터넷 게이트웨이 클릭 👉 작업 👉 VPC에 연결 방금 만든 VPC를 클릭하고 연결 버튼 클릭✔ Detached 👉 Attached 상태로 확인 완료

서브넷과 라우팅 테이블, 서브넷을 설정을 한뒤, 이번에 추가 작업을 해야 한다.

9. 추가 작업

서브넷으로 들어가 작업 👉 라우팅 테이블 연결 편집 라우팅 테이블이 기본 값으로 설정되어 있는데, 방금 만든 라우팅 테이블로 변경 라우팅 테이블로 들어가 작업 👉 라우팅 편집 클릭✔ 라우팅 추가 👉 0.0.0.0/0으로 설정 한 후, 방금 만든 인터넷 게이트웨이 설정

나만의 VPC 설정이 완료되었다. 이제 내가 만든 VPC를 인스턴스에 적용해보자.

** EC2 포스터**를 참고해보자. https://velog.io/@dev_96/AWS-AWS-EC2

📍 참고: 인스턴스를 만들 떄 내가 만든 VPC으로 설정을 해야 한다.

이제 접속을 해보자.

다운로드 완료 ✔ 외부와의 통신도 완료 ✔

내가 만든 VPC 확인 결과: 다운로드 완료✔ 외부와의 통신도 완료✔

이렇게 다운로드도 완료했고, 외부와의 통신도 완료했다. VPC는 생각보다 간단했다. 더 나아가, VPC끼리 통신하는** VPC Peering**도 있다. 오늘은 여기서 마치겠다.

1.Jenkins NodeJS 설치

Jenkins 관리 👉 플러그인 관리에 들어간다.

2. Plugins

NodeJS 검색을 한 뒤, Download now and install after restart 설치를 진행한다.

3. Global Tool Configuration

Jenkins 관리 👉 Global Tool Configuration 에 들어간다. NodeJS 플러그인을 찾아 Name과 버전을 입력한다. Nodejs 최신 버전도 있으니 걱정마라!! 필자는 16.4.21으로 진행하겠다. 저번 포스트에 Github 연동하면서 만들었던 프로젝트 👉 Configure 👉 빌드 Steps 👉 NodeJS 플러그인 설정

📍 사전 필수 ✔ 반드시 GitHub 연동과 git Webhook 설정이 되어야 한다.

** 링크를 참조하자.** 👉 https://velog.io/@dev_96/AWS-%EC%A0%A0%ED%82%A8%EC%8A%A4Jenkins-1

사전 준비가 되었으면, 다음으로는 젠킨스에서 노드 서버로 전송하기 위해서는 ssh를 이용해야 하는데, 젠킨스에서는 플러그인으로 제공한다. Publish Over SSH 플러그인을 설치해야 한다.

필자는 Publish Over SSH를 설치하였다. 👉 https://dbjh.tistory.com/68?category=839984

Node.js 서버를 배포하는 방식은 여러가지이지만, 그 중 하나인 PM2를 이용할 것이다.

npm install -g pm2
pm2 -v ✔ 버전 확인

이렇게 큰 PM2 로고가 나오면 성공 ‼

PM2를 설치 한 뒤, EC2에 Node.js 설치를 해야 한다. Node.js 설치는 간단하다.

이렇게 친절하게** Amazon** 에서 설명을 해준다. 역시 GOD 아마존 🌟 👉 https://docs.aws.amazon.com/ko_kr/sdk-for-javascript/v2/developer-guide/setting-up-node-on-ec2-instance.html

4. 자동 스크립트 구성

이제 중요한 자동 업데이트 스크립트 구성을 해야한다. 자동배포를 구성하기 전에 젠킨스에 의해 실행될 스크립트를 작성하자. 스크립트 파일은 깃허브에서 클론한 폴더 내부에 작성하자.

git clone 내 허브 주소

#!/bin/bash
git pull
npm install
npm start

필자는** start.sh** 이름으로 저장했고, 권한을 주자‼

chmod 755 start.sh 

start.sh가 실행이 잘 된다. 기분이 좋구만!!

이제 젠킨스 서버에서 쉘 스크립트를 작성하자.

5.배포 서버 설정

1.이제 젠킨스 서버로** SSH 접속**해서 젠킨스 사용자로 유저를 변경

ssh-keygen -t rsa 

ssh 키를 발행하고 엔터 누르고 진행

ssh키를 복사한 것을 붙여넣기 한다.

 vi ~/.ssh/authorized_keys

chmod 700 ~/.ssh
chmod 600 ~/.ssh/*
✔ ssh 권한을 준다.

✔ ssh 접속 성공

ssh 사용자명@node.server ip
✔ ssh 접속 성공

🔥 마지막으로 테스트

연동된 리포지토리에 소스코드를 push 해보고 젠킨스 서버에 문제없이 작동되는지 확인하자

1. 기존에 있던 글을 지우고, dev, dev.96블로그입니다. 작성

2. 깃 허브에 push

3. 깃 허브 push 완료!!

4. 연동된 리포지토리에서 git pull

5. 젠킨스에서 Buildnow ✔

6. 서버 ip 입력👉 자동배포 서버 구축 완료✔

이로써 Jenkins + Node.js + GitHub 를 이용한 자동배포 구축이 완료되었다. 서버에서 SSH 접속 후, Bulid된 파일을 서버로 모두 전송했다. 다시 Jenkins를 실행함으로써 수정한 파일이 배포가 마무리 되었다.

기회가 된다면,** GitLab** 을 통해 배포를 해보고 싶다는 생각이 들었다. 아니면 AWS 서비스에서 파이프라인과 배포 서비스를 이용해보고 싶다. 다음 포스트가 기대된다.

⭕ 예외:

git pull 오류가 났다.

또 구글 박사님한테 물어보던 중, 참고할만한 글이 있어 링크를 남긴다. 👉 https://insapporo2016.tistory.com/53

1. EC2 인스턴스에 접속

*접속 방법은 포스트를 확인하자 ✔ * 👉 https://velog.io/@dev_96/AWS-AWS-EC2

📍 추가적으로 보안그룹을 셋팅해야 한다. Jenkins는 8080번 포트이기 떄문에 8080번 포트는 설정한다.

2. 젠킨스(Jenkins) 설치 코드

wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo
rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key

amazon-linux-extras install -y java-openjdk11 Installing java-11-openjdk
👉 젠킨스는 JAVA로 돌아간다. 그러므로 JAVA를 설치해야한다.

yum install -y jenkins 
systemctl start jenkins.service

systemctl enable jenkins 👉인스턴스 접속이 끊어지면 다시 젠킨스 시작을 해야 하는데,
이 코드를 입력하면 자동적으로 젠킨스가 시작된다.

3. 젠킨스 실행 완료

Systemctl status jenkins.service 명령어를 입력할 때 아래 사진처럼 나오면 정상적으로 젠킨스 설치가 되었다.

4. 젠킨스 홈페이지 접속

퍼블릭ip:8080으로 접속을 하면, 다음과 같은 웹페이지 화면이 나오는데, 계정의 암호를 입력을 해야한다. 화면에 보이는 파일에 암호가 적혀있다.

cat /var/lib/jenkins/secrets/initialAdminPassword

해당 명령어를 입력하면 암호 확인이 가능하다.

5. 플러그인 설치

아래의 화면과 같이 두 개의 선택 설치 화면이 나온다. 필자는 ✔ 추천 플로그인을 설치하겠다.

6. 계정 생성

계정을 생성해준다.

7. 정상적으로 설치 확인 완료

젠킨스가 정상적으로 ✔ 설치 완료 되었다.

젠킨스가 설치가 되었고, 이번에 깃허브 연동에 대해서 설명하겠다.

Jenkins와 Github 연동

1. 깃허브에 접속할 SSH키 생성

mkdir /var/lib/jenkins/.ssh
ssh-keygen -t rsa -f /var/lib/jenkins/.ssh/ 만들고자 하는 키 이름

2. 깃허브 👉 Settings 👉 Deploy keys 👉 Add deploy key

생성한 SSH키를 복사붙여넣기 하면 된다.

⭕ 주의해야 할 점: Github에다 등록해야 하는 키는 public 키이다. pub 파일 형식인 키를 등록하면 된다. 필자는 이거 해결하느라 죽을 뻔..

✔ key 키 확인 방법

cd /var/lib/jenkins/.ssh
cat 만들고자 하는 키 이름.pub

3. Jenkins Manage Credential 등록

대시보드 👉 Jenkins 관리 👉 Manage Credential

add credentials 클릭

kind 👉 SSH Username with private key ID 입력 👉 Username 입력 👉 Private key 등록

📍 Private key

cd /var/lib/jenkins/.ssh
cat 만들고자 하는 키 이름

4. 생성 완료

Jenkins Manage Credential이 ✔ 완료되었다.

드디어 반까지는 왔다. 좀만 더 힘내보자.

젠킨스(Jenkins) ITEM 생성

1. ITEM 생성

대시보드 👉 새로운 ITEM 👉 Freestyle project

2. 소스코드 관리

소스 코드 관리 👉 git 👉 Repositort URL ✔ 내 깃허브 주소 입력 Credential ✔ 아까 만들었던 Credential 등록

3. Github Webhook 설정

Payload URL 설정에 📍 젠킨스 IP:포트/github-webhook 입력한다. Content type에 application.json으로 설정한다.

🌟🌟 해당 Github 저장소에서 푸쉬가 일어나면 젠킨스를 호출한다. 🌟🌟

Jenkins와 Github 연동 완료

👏 결과적으로 젠킨스에 Github 파일이 빌드업 되었다. 👏

드디어 끝이 났다. 처음 해보는 CI/CD 였는데, 하는 동안 재미있었고, 과정에 대해 많이 이해했다. CI/CD에 대해서 공부를 더 해야겠다. 이만..오늘은 여기까지

🔥 추가적으로 Troubleshooting

빌드업 성공하기 전에 실패가 2번 있었다. 아래화면과 같이 로그를 확인해보니 branch를 찾을수 없다는 이야기인것 같다.

구글박사에 물어보던 중, 요즘 원인이 github 브랜치의 경우 master가 아닌** main이 주 브랜치로 쓰이는 것 같다는 글을 ✔ 발견 빛의 속도로 */master** 👉 */main 으로 변경하니 에러가 해결되었다. 휴우.. 🏆 성공했다.

CI/CD

CI/CD란 (Continuous Integration/Continuous Delivery)는 자동화하여 애플리케이션을 짧은 주기로 제공하는 방법이다.

기본적인 개념 ‼

✔ ** 지속적인 통합 ** ✔ *지속적인 서비스 제공 * ✔ *지속적인 배포 *

CI (지속적 통합)

개발자를 위한 자동화 프로세스를 통해 새로운 코드 개발과 코드의 변경 사항이 정기적으로 빌드 및 테스트 되고, 공유 레포지토리에 병합되어 여러 명의 개발자가 동시에 어플리케이션 개발과 관련된 코드를 작업할 경우에도 서로 충돌없이 원하는 개발 작업을 수행하고 문제 해결한다.

CD (지속적인 서비스 제공 및 배포)

개발자가 지속적인 서비스 전달과 배포를 통해 새로운 코드에 대한 배포를 자동화할 수 있으며, 신속한 어플리케이션을 제공할 수 있도록 도움을 주는 역할은 한다.

CI를 통한 빌드의 자동화 및 유닛의 통합 테스트 수행 이후 이어지는 CD 프로세스는 유효한 소스코드를 레포지토리에 자동으로 전달한다. 따라서 개발 파이프라인 CI가 먼저 구축되어야 한다.

서론이 길어졌다. 젠킨스에 대해서 글을 써야겠다.

"젠킨스(Jenkins)"

앞서 설명하다시피 CI/CD에 대해서 환경을 구축하기 위한 도구가 바로 "젠킨스(Jenkins)"이다.

✔ 편리한 설정 ✔ *안정적인 빌드/배포 환경 * ✔ ** 다양한 활용 및 손쉬운 확장 **

이 세 가지가 모두 포함되어 있다. 나는 위 세가지 이유로 젠킨스를 도입하였다. 오늘은 여기까지 설명 하고, 다음 포스트에서는 EC2에 젠킨스 설치와 깃허브 연동에 대해서 기본 환경 및 설치 과정을 정리해보겠다. :)

유튜브 강의는 보면서 가장 도움이 됐었다. https://youtu.be/Wus-fC15elM 👍 동빈나님 채널

첫번째로 소개한 서비스는 AWS EC2 이다.

EC2 ( Elastic Compute Cloud) 이란 🔍

• AWS EC2는 Elastic Compute Cloud의 약자로 독립된 가상의 컴퓨터를 임대해 주는 웹 서비스이다. • AWS에서 제공하는 클라우드 컴퓨팅 서비스 = 클라우드 가상 서버 • EC2 클라우드 가상 서버를 "인스턴스" 라고 부른다. • 인스턴스 유형: 인스턴스를 위한 CPU, 메모리, 스토리지, 네트워킹 용량의 여러 가지 구성 제공 • 키 페어를 사용하여 인스턴스 로그인 정보 보호

말 그대로 PC방과 같이 돈을 내고 우리가 PC를 이용하는 것처럼 EC2도 사용한 만큼 비용을 지불한다.

📍 요약 : EC2 서비스는 AWS에서 비용,성능,용량에서 클라우드 컴퓨팅을 제공하는 서비스이며, 네트워크, 스토리지가 구성된 서버를 OS만 선택하여 제공하는 서비스이다.

이제 AWS EC2 인스턴스를 생성해보자.

1. AWS EC2 인스턴스 생성 AWS 검색창에 EC2를 입력하고, 결과 내에 EC2 서비스를 클릭한다.

2. 인스턴스 이름 설정 인스턴스 이름을 설정

3. 인스턴스 유형 선택 인스턴스 OS, 성능을 선택, AWS Linux에서 프리티어 사용 가능한 인스턴스 유형 선택

4. 키 페어 생성

키 페어는 보안 인증서이기 때문에, 안전한 곳에 보관을 해야 한다. 만약 잃어버린다고 하면, 보안 취약에 너무나도 큰 문제이다.

키 페어 이름을 입력하고, 나는 Putty 프로그램을 활용하여 인스턴트에 원격접속을 할 예정이기 떄문에 키 파일 형식은** ppk**로 하였다.

5. 네트워크 설정 보안 그룹 생성과 기존 보안 그룹 선택이 있다. 필자는 보안 그룹을 생성하고 추후에 보안 그룹에 대해 따로 설정할 예정이다. SSH 트래픽 허용 0.0.0.0은 모든 IP에 대해 SSH로만 접속하면 모든 허용한다는 소리다.

6. 스토리지 설정 인스턴스 스토리지를 설정한다. 필자는 스토리지 용량이 충분하기 떄문에 기본으로 하겠다.

7. 대망의 인스턴스 생성 완료 드디어 인스턴스 생성이 완료되었다. AWS를 공부하면서 아마 EC2를 가장 먼저 접하고, 가장 많이 이용할 것이다.

이제 인스터스를 생성하였으니, 접속해보자 ✨ PUTTY라는 프로그램이 있다. 접속 방법에 대해서는 링크를 참조하자.

https://m.blog.naver.com/jeonsr/221792705148

1. PUTTY 접속해서, HOST NAME에 EC2 인스턴스 IP를 입력한다.

2. 아까 다운로드 받았던 키 페어를 인증받는다.

3. 대망의 PUTTY 인스턴스 접속

이렇게 인스턴스를 생성하고, 접속해보았다. AWS 공부를 하면 인스턴스 생성, 접속은 수없이 할 것이다. 오늘도 이렇게 EC2 개념 정리와 생성,접속을 정리해보았다. 하나하나 차근차근 정리해보자 🔥🔥

국내 클라우드 시장 점유 순위가 나왔다. 점유율 1위는 아마존 웹서비스, 2위는 마이크로소프트, 3, 4위는 구글, 네이버가 차지했다. (https://zdnet.co.kr/view/?no=20221228091202) 📄 기사 참조

이렇게 클라우드 시장의 대장이었던 아마존은 사실 시작은 아주 작았다. 계획은 이러했다. 만약 서버를 만들어야 한다고 참조하자.

1. 하드웨어
2. 네트워킹 장비
3. 전원공급장치
4. 환경 제어장치
5. 백업 발전기
6. 운영 인력 등등

사실상 서버를 운영하는게 비용도 많이 들고 힘들다. 하지만, 클라우드의 출현으로 데이터센터 구축 비용과, 서버 구매 비용을 확 줄일 수 있었다. 이것이 AWS가 클라우드 끝판왕이라는 소리를 듣는 이유다.

1. AWS 계정 생성
2. EC2 생성
3. VPC 생성
4. Internet Gateway, ROUTER53 -> VPC 연결

클릭 몇 번으로 서버를 구축 및 운영 할 수 있다. 또한 AWS를 인터넷만 있으면 언제든지 접속 할 수 있다는게 큰 장점이다. 그래서 많은 기업들이 서버에서 클라우드로 전환하는 마이그레이션 서비스를 한다.

✨TMI : 데이터 센터 및 기타 인프라에서 호스팅 되는 데이터를 laaS PaaS 클라우드 배포로 전송하는 것이다. (클라우드 마이그레이션)

이것이 AWS (아마존 웹 서비스)이다.

소프트웨어공학 전공자였던 나는 Front 위주로 공부를 하였고, 개발 분야에서도 프로젝트를 만들었었다. 다른 분야도 공부하고 싶은 욕심에 클라우드 분야에도 흥미를 느꼈고, 블로그를 작성하면서 내 공부 지식을 정리할 생각이다.

잘 해보자!!! 🔥🔥🔥