최씨네 블로그

Java 특징

도라지보다더덕 — Sun, 6 Dec 2020 02:44:09 +0900

Java

Java는 1995년에 Sun Microsystems에서 발표한 언어로 점차 인터넷이 발전하면서 다양한 기종의 컴퓨터들과 운영체제들이 나타났고 이러한 플랫폼들로부터 독립적으로 동작하기 위해 고안된 언어입니다. C/C++로 만들어졌으며 C++의 장점을 그대로 흡수하고 단점은 제거한 완전한 객체지향 언어입니다.

Java 언어의 특징(C++과 비교해 달라진 점)

- C++는 객체를 생성했을 때 delete 키워드를 사용해 제거해야합니다. 만약 프로그래머가 실수로 생성된 객체를 지우지 않을 경우 프로그램이 돌아가면 돌아갈수록 메모리에 불필요한 객체가 점점 쌓이게 됩니다. 따라서 프로그래머가 직접 객체를 지우지 않고 Gargarbage collection을 이용해 알아서 지워지도록 설계했습니다.

- 이차이상의 포인터에서 생기는 문제들을 제거하기 위해 Java에서는 포인터 변수를 제거하고 참조 변수만을 사용하도록 설계했습니다.

- 데이터 구조를 선언하는 방식으로 struct와 class가 존재했는데 struct 키워드를 지우고 class만을 사용합니다.

- 함수지향과 객체지향을 혼합하여 사용하는 방식에서 완전한 객체지향 언어로 사용하도록 설계했습니다.

- 언어 자체에 컬렉션을 포함하고 글로벌 문자 데이터 처리의 복잡성을 다양한 인코딩을 지원하여 해결했습니다.

이외에도 많은 차이점이 있지만 크게 요약을 하자면 아래와 같습니다.

C++와 비교했을 때 간결함

언어 자체에 포함된 컬렉션

완전한 객체지향 언어

자바 플랫폼의 특징

자바는 JVM이라는 가상 환경 위에서 동작합니다. 즉, 다른 플랫폼(운영체제)에서 독립적이다 라고 할 수 있습니다.

C나 C++ 같은 경우는 CPU나 운영체제가 달라질 경우 컴파일러 또한 달라져야 하지만 java는 JVM위에서 동작하므로 이러한 고민을 하지 않아도 됩니다.

이는 WORA (Write Once, Run Anywhere) 이라는 한번 쓴 코드는 어디에서든 동작하자 라는 철학에서 나온 특징입니다. 따라서 한번 작성된 코드는 모든 곳에서 실행되며 어떤 운영체제이든 위에 자바 플랫폼만 설치하면 동작할 수 있습니다.

자바 번역기 특징 (컴파일러)

자바는 다음과 같은 순서로 기계어로 된 물리코드로 번역됩니다.

이때 중간 코드 생성까지를 자바 컴파일러를 통해 생성합니다. 즉, 개발자가 자바 컴파일러를 통해 컴파일한다 라는 의미는 이 중간 코드를 생성한다는 의미입니다. 컴파일할 경우 .class 파일(= 바이트 코드 = 가상 cpu 코드 = 중간 코드)이라는 파일 유형의 형태로 저장됩니다.

그 이후는 실행과정입니다. 생성된 .class 파일을 JIT를 통해 동적으로 컴파일하고 인터프리트 방식으로 물리적인 코드로 변경하고 실행합니다.

우리가 흔히 JDK라 말하는 것들은 위 개발부터 실행까지 모든 과정에 필요한 도구(컴파일러, 디버거, JIT, Garbage collection 등)들이며 실행환경에 필요한 필요한 여러 도구(JIT, Garbage collection, Security, Loader 등)를 JRE (자바 실행 환경)이라고 부릅니다.

컴파일러를 통해 중간코드가 생성됩니다. 이때 생성된 중간 코드는 가상의 cpu를 염두에 둔 바이트 코드입니다. 이 중간 코드는 어셈블리어로 변환된 뒤 이진 코드로 변환되는 과정을 거쳐야 하는데 중간 코드를 어셈블리어로 변환하는 과정은 인터프리트 방식으로 합니다.

reference

www.youtube.com/watch?v=5-ZiX4wRDpI&list=PLq8wAnVUcTFV4ZjRbyGnw6T1tgmYDLM3P&index=8

ko.wikipedia.org/wiki/%EC%9E%90%EB%B0%94_(%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D_%EC%96%B8%EC%96%B4)

자바 (프로그래밍 언어) - 위키백과, 우리 모두의 백과사전

위키백과, 우리 모두의 백과사전. 자바Java패러다임프로그래밍 패러다임: 객체 지향 프로그래밍 (클래스 기반 프로그래밍), 구조적 프로그래밍, 명령형 프로그래밍, 제네릭 프로그래밍, 반영, 병

ko.wikipedia.org

medium.com/@ahn428/java-java%EC%9D%98-%ED%83%84%EC%83%9D%EA%B3%BC-%ED%8A%B9%EC%A7%95-1fd163df5858

Java - Java의 탄생과 특징

1. Java의 탄생

medium.com

2. Apache 컴파일 설치

도라지보다더덕 — Thu, 24 Sep 2020 23:05:09 +0900

Apache

apache http 서버란 apache 소프트웨어 재단에서 관리하는 서버 프로그램을 말합니다. 따라서 우리가 흔히 부르는 apache는 서버 프로그램에 대해 모호하게 재단을 부르는 것과 마찬가지입니다. 저는 apache 소프트웨어 재단에서 만든 웹서버 httpd를 설치하여 서버 프로그램을 구축해보겠습니다.

이전에 설치한 우분투에는 정말 아무것도 없으니 gcc, g++ 등 모두 설치해줍니다. (apache 소스코드를 컴파일하기 위해 필요합니다.)

소스코드 받기 전 필요한 것들

gcc : apt install gcc
g++ : apt install g++
make: apt-get install make
pcre & pcre-dev: 정규표현식

PCRE & pcre-dev

pcre-dev는 패키지 매니저를 통해 다운받았습니다.

그 후 pcre를 다운받아 압축해제하고 ./configure를 실행해 설치될 주소를 설정합니다.

apt-get install pcre-dev		#패키지 매니저로 설치 ㅠ

wget ftp://ftp.pcre.org/pub/pcre/pcre-8.44.tar.gz	#소스코드 가져오기
tar xvfz pcre-8.44.tar.gz 					#압축해제
cd pcre-8.36		


./configure --prefix=/usr/local			#설치위치 설정


make			#빌드
make install		#설치

다음은 apache 코드를 네트워크 상에서 다운받아옵니다. 이 때 명령어로 wget을 사용하는데 wget은 web get의 약자로 네트워크 상 데이터를 다운받을 때 쓰는 명령어입니다.

아래 apache 페이지를 보면 안정화된 버전이 2.4.46이라고 나옵니다. 따라서 2.4.46 버전을 다운받겠습니다.

wget을 통해 압축된 소스코드를 받아옵니다.

wget http://apache.mirror.cdnetworks.com/httpd-2.4.46.tar.gz

apache 2.4.46 다운 받을 시 필요한 apr-util1.6.1 버전과 PCRE8.44 버전이 필요하다고 명시되어있습니다. 따라서 위와 마찬가지로 설치해줍니다. (PCRE는 위에서 설치했습니다)

apr-util을 받기 전에 apr을 받아줍니다. 그 후 apr-util을 받아줍니다. apr-util1.6.1에 apr 1.7.0이 필요하다고 명시되어있으므로 따로 받아주었습니다.

wget http://apache.tt.co.kr/apr-1.7.0.tar.gz
wget http://mirror.navercorp.com/apache//apr/apr-util-1.6.1.tar.gz

압축된 파일을 네트워크상에서 받아왔으면 이제 압축을 풀어줍니다.

#압축 해제

tar xvfz httpd-2.4.46.tar.gz
tar xvfz apr-1.7.0.tar.gz 
tar xvfz apr-util-1.6.1.tar.gz

#아파치 소스라이브러리로 압축해제된 파일을 옮겨줍니다.
mv apr-1.6.3 httpd-2.4.46/srclib/apr
mv apr-util-1.6.1 httpd-2.4.46/srclib/apr-util

cd httpd-2.4.46

mkdir /usr/local/victolee		#해당 디렉토리는 여러 라이브러리를 모아두기 위한 디렉토리입니다.

apt-get install libexpat1-dev		


./configure \
--prefix=/usr/local/victolee/apache2.4.33 \
--with-included-apr \
--with-pcre=/usr/local/bin/pcre-config

make
make install

cd /usr/local/victolee/apache2.4.33

이제 설치가 완료되었습니다. 만약 apache에 대한 설정을 바꾸고싶다면 설치된 곳에 conf/httpd.conf 파일을 수정하면 됩니다.

마지막으로 실행하기 위해서

cd /usr/local/victolee/bin

./apachectl start		#데몬 시작
./apachectl stop		#데몬 정지

아무 브라우저에 들어가서 localhost로 접근했을 때 다음과 같이 나오면 실행 성공입니다!

reference

victorydntmd.tistory.com/220

[Web Server] 아파치( Apache ) 2.4.33 컴파일 설치

CentOS 7에서 Apache 2.4.33 버전을 컴파일해서 설치하는 방법에 대해 알아보겠습니다. 아파치 2.0.64 설치와의 차이점 1) apr (Apache Portable Runtime ) , apr-util 아파치 2.0을 설치할 때는 yum으로 apr,..

victorydntmd.tistory.com

1. 가상환경 설치

도라지보다더덕 — Thu, 24 Sep 2020 18:24:39 +0900

서버 구축 전에..

서버를 구축하기 앞서 서버를 구축할 운영환경을 설정하겠습니다. 보통 서버를 구축하는데에 사용하는 운영체제는 linux 계열의 운영체제입니다. 리눅스를 활용하는 이유는 바로 무료 오픈소스라는 점에 있습니다. 또한 여러 서버 구축에 관련된 도구들을 패키지 매니저를 활용해 손쉽게 설치할 수 있습니다. 물론 서버를 운영하기위해 윈도우를 사용하려면 할 순 있겠지만 굳이 비싼 돈 주고 설정하기도 어려운 환경을 설치할 필요는 없습니다. 따라서 저는 무료 OS인 우분투를 활용하여 서버를 구축하겠습니다.

가상머신

우선 리눅스를 설치할 가상머신을 다운받겠습니다. 가상 머신이란 운영체제 위에서 가상으로 돌아가는 운영체제를 설치할 수 있도록 해주는 말 그대로 가상머신입니다. 대표적으로 VirtualBox와 VMWare가 있지만 저는 무료인 VirtualBox를 사용하겠습니다.

1. 아래 페이지에 들어가 본인 OS에 맞는 버전을 다운로드 해주세요.

www.virtualbox.org/wiki/Downloads

Downloads – Oracle VM VirtualBox

Download VirtualBox Here you will find links to VirtualBox binaries and its source code. VirtualBox binaries By downloading, you agree to the terms and conditions of the respective license. If you're looking for the latest VirtualBox 6.0 packages, see Virt

www.virtualbox.org

2. 다운로드 후 쭉쭉 설치하면 다음과 같이 진행됩니다.

# Error

mac에서 "설치할 수 없습니다. " 가 뜰 경우 '시스템 환경설정 > 보안 및 개인정보보호 > 일반' 탭에서 VirtualBox를 허용으로 변경해주세요!

3. 성공적으로 설치되었으면 VirtualBox를 실행해주세요. 다음과 같은 화면이 나타납니다.

4. 새로만들기 버튼을 누르고 자신의 가상환경 이름을 설정해주세요. 그리고 설치할 운영체제 종류도 다음과 같이 설정해주세요.

5. 계속해서 진행합니다. 가상환경에 할당할 메모리를 설정해줍니다.

6. 가상환경이 사용할 저장공간을 할당해줍니다.

7. 물리적 하드 드라이브를 저는 고정크기로 할당했습니다. 고정크기가 더 빠르다고 하네요. 하지만 본인이 편하신대로 하면 됩니다.

8. 할당할 하드 디스크 크기를 설정해줍니다.

9. 설정이 완료되면 다음과 같은 화면이 나타납니다.

10. 이제 운영체제를 설정해주어야하는데요. 운영체제는 저 같은 경우는 우분트를 다운받았습니다. 아래 페이지에서 다운받아주세요.

ubuntu.com/download/desktop

Download Ubuntu Desktop | Download | Ubuntu

Ubuntu is an open source software operating system that runs from the desktop, to the cloud, to all your internet connected things.

ubuntu.com

11. 이제 만든 가상환경의 설정을 해줄 차례입니다. 가상환경 클릭 후 설정버튼을 눌러 다음과 같은 저장소 탭에 들어가주세요.

컨트롤러: IDE 밑에 비어있음으로 되어있는 것을 확인할 수 있습니다. 옆 IDE 세컨더리 마스터의 디스크 모양을 눌러주세요.

12. 아까 다운로드한 우분투 이미지를 선택해주세요.

13. 이제 시작 버튼을 눌러 가상환경을 실행하면 됩니다.

만약 위와 같이 에러 메세지가 발생하면 스크립트로 직접 실행해주세요.

ViratulBoxVM -- startvm [가상환경이름]

운영체제 설치

가상환경을 설치하고 나면 자동으로 아까 설정한 운영체제가 실행됩니다. 그럼 아래와 같이 쭉 실행하시면 성공적으로 설치됩니다.

이것으로 가상환경 및 운영체제를 설치했습니다. 다음으로는 서버 프로그램인 Apache를 설치해보도록하겠습니다.

0. 서버 개요

도라지보다더덕 — Thu, 24 Sep 2020 01:30:25 +0900

서버란?

서버(영어: server)는 클라이언트에게 네트워크를 통해 정보나 서비스를 제공하는 컴퓨터 시스템으로 컴퓨터 프로그램(server program) 또는 장치(device)를 의미한다.

출처 - 위키백과

서버란 말 그대로 무언가를 Serve(제공)하는 -er(행위자)를 뜻합니다. 이해를 돕기 위해 아주 재밌는 이야기 하나를 해보겠습니다.

어느 한적한 마을에 놀러가 식당에 들어갔습니다.

저는 무엇을 먹을지 정하기위해 종업원에게 메뉴판을 요청했습니다.

종업원은 메뉴판을 가져다 주었고 저는 한참을 고르다가 마침내 도라지 구이를 주문했습니다.

그러자 종업원은 주방으로 달려가 도라지구이 하나를 주방장에게 요청하고 다시 돌아와 다른 손님들을 받았습니다.

주방에서는 주문을 확인하고 도라지구이를 만들기 위해 스마트 냉장고에 도라지를 달라고 요청했습니다.

그러자 스마트 냉장고에서 냉장고 자체에 도라지가 있는지 검사하고 꺼내어 주방장에게 가져다주었습니다.

위 예시를 IT 용어로 바꿔보면 다음과 같이 볼 수 있습니다.

손님 - Client

종업원 - Server Program (Web Server)

주방장 - Backend language (php, jsp, java, python 등)

스마트 냉장고 - DBMS (My Sql, MariaDB 등)

냉장고 - DB (데이터 집합)

도라지 - data

Client <-> Server Program <-> Backend language <-> DBMS(DB)

따라서 위 상황은 다음 상황과 일치합니다.

클라이언트가 웹서버에게 요청을 합니다.

그러자 웹 서버는 내가 줄 수 있는 것들(메뉴판 == 정적 컨텐츠)들은 직접 반환해주고 내가 줄 수 없는 것들(도라지 구이 == 동적 컨텐츠)들은 Backend Language를 통해 작성한 프로그램에 맡깁니다.

요청을 받은 프로그램은 요청을 수행하기 위해 필요한 데이터들을 DBMS에게 요청합니다.DBMS는 데이터 베이스에 있는 데이터에 접근하여 데이터에 대한 요청을 수행해줍니다.

(DBMS란 데이터베이스 관리 시스템입니다. DB는 데이터 집합을 말하고 DBMS는 데이터 베이스에 접근하게 해 주는 소프트웨어 도구의 집합입니다.)

따라서 상황을 잘 분석해보면 다음과 같은 특징을 알 수 있습니다.

N:1 (Client : Server)
client - server란 상대적인 개념

우선 클라이언트와 서버는 N : 1의 관계를 가집니다. 만약 손님 한명당 종업원 한 명, 음식 하나당 주방장 한 명씩이 더 필요하다면 배보다 배꼽이 더 큰 격일 겁니다. 따라서 일손이 모자라지 않는 한 하나의 서버는 클라이언트의 여러 요청을 수행할 수 있어야 합니다.

두 번째 특징으로는 서버와 클라이언트는 상대적인 개념이란 것입니다. 손님의 입장에서는 종업원이 서버입니다. 하지만 종업원 입장에서는 주방장에게 요청을 하므로 주방장이 서버입니다. 즉, 서버란 무언가를 제공해준다는 점에서 서버라고 부릅니다.

따라서 흔히 우리가 서버를 구축한다는 표현은 Server program <-> Backend Language <-> DBMS 가 작동하는 환경을 의미합니다. 서버에 대한 이해를 깊이 하기 위해 저는 Server program의 대표주자 Apache, Backend language의 php, DBMS의 My Sql를 컴파일 설치를 통해 구축해보도록 하겠습니다.

CI/CD 적용하기

도라지보다더덕 — Fri, 4 Sep 2020 01:37:23 +0900

개요

DevOps

DevOps란 개발과 운영을 함께하는 소프트웨어 개발 방법론입니다. 소프트웨어 개발 시에는 개발뿐만 아니라 빌드, 테스트, 배포 등 여러 과정이 필요합니다. 따라서 기존의 회사들은 하나의 서비스를 개발과 운영팀으로 나눠 관리했습니다. 이렇게 하나의 서비스를 개발과 운영으로 나누다보니 의사결정과 소통에서 비효율적인 문제가 발생했습니다. 따라서 개발과 운영을 함께 할 수 있는 방법론인 DevOps가 탄생하였습니다.

하나의 서비스를 개발한 후 운영하다보면 필연적으로 그 서비스는 여러 변경사항이 생깁니다. 과거에는 이 변경된 코드를 적용하기 위해서 모든 개발자가 모여 직접 코드를 병합하였습니다.

최근에는 애플리케이션 배포 주기가 짧아지면서 잦은 코드 병합이 일어나고 이 때마다 여러 개발자가 모여 직접 병합할 경우 생산성 저하라는 문제가 발생되었습니다. 배포 또한 마찬가지로 여러 서버에서 배포를 진행해야한다면 수동으로 배포하기엔 실수를 할 가능성이 높아지고 특히 서버가 몇 백대라면 수동 배포에 한계가 존재하게되었습니다.

따라서 통합과 배포를 자동화하여 운영해주는 DevOps의 CI/CD 개념이 탄생하게되었습니다.

CI/CD 란?

CI(Contiuous Integration): 지속적 통합을 의미하는 용어로 추가되거나 수정된 코드들을 실시간으로 병합하여 안정적인 배포 파일을 만드는 과정을 의미.
CD(Contiuous Deployment): 지속적인 배포를 의미하는 용어로 병합된 코드를 자동으로 배포해주는 과정을 의미

CI란?

CI지속적 통합는 지속적으로 퀄리티 컨트롤을 적용하는 프로세스를 실행하는 것이라고 정의가 쓰여있습니다. 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어서 하나의 레포지토리로 관리되는 것을 의미합니다.

SCMSource Code Management의 과정도 CI에 속합니다.
- Git을 사용해 Github 레포 하나로 여러명의 개발자가 소스코드를 올리고 충돌을 처리하는 모든 과정도 CI에 속합니다.
- Git이 아닌 SVN도 마찬가지입니다.
빌드 후 작성된 테스트 코드를 통해 유효성을 검증하는 것도 CI에 속합니다.
- 아주 간단한 예시로 Pull Request를 생성했을 때, 소스코드가 Conflict나는 경우 Merge 버튼이 비활성화 되는 경험을 해보셨을 겁니다. 그것 또한 유효성 검사에서 실패한 것으로 CI에 속합니다.
- 더 나아가, CI 툴을 사용해 소스코드가 컨벤션에 준수하는지 등을 체크하는 린터linter로 검증을 하도록 할 수 있는 등 다양한 일이 가능합니다.

CI를 하면 뭐가 좋은가요?

지속적 통합을 하게되면 소스코드는 항상 Ready-to-run 상태(배포가 가능한 상태는 아닙니다.)가 됩니다. 즉, 중간에 누군가 합류를 해도 빌드가 되는 코드를 받을 수 있습니다.
- 혼자서 개발할 때는 이런 문제를 겪어보지 못해서 중요성을 체감하지 못합니다.
- 하지만, 회사 프로젝트나 오픈소스 프로젝트 등 여러명이서 개발을 하는 상태라면 이 문제는 더욱 중요해집니다.
  - 중간에 합류해서 새로운 기능을 개발하려고 하는데 누군가 작업하고 있는 코드가 아직 공유 레포upstream에 올라가 있어서 빌드가 안된다.
  - 이런 경우가 발생하면 그 사람과 얘기해서 해결하던가, 직접 소스코드를 보고 돌아가도록 디버깅을 하던가 해야합니다. 하지만, 이 자체로도 시간이 소요되므로 생산성이 매우매우 떨어지게 됩니다.
- 게다가, 특정한 날을 정해서 각자 개발한 소스코드를 병합하도록 하게되면 그에 따르는 많은 시간을 소모하게 됩니다.
  - 만약, 기존 코드와 Merge한 코드가 에러가 난다면 이를 처리하는 과정에도 많은 시간이 소요될 것입니다.
항상 양질의 코드 퀄리티를 유지할 수 있습니다.
- 테스트의 자동화를 이루게되면 항상 테스트 코드를 통과하는 코드만 공유 레포에 올라갈 수 있기 때문에 상당한 퀄리티의 소스코드로 유지되게 됩니다.

CD란?

CD는 지속적 제공Continuous Delivery과 지속적 배포Continuous Deployment를 모두 의미합니다.

지속적 제공Continuous Delivery : CI 과정이 모두 끝난 뒤 유효성 검증이 된 코드를 레포지토리에 올리는 것을 자동화합니다. (프로덕션 레벨로 배포하는 것과는 별개입니다.)
- 항상 프로덕션 레벨로 배포할 수 있는 준비가 되어있는 소스코드를 자동으로 올라갈 수 있도록 합니다.
지속적 배포Continuous Deployment : CI/CD 과정의 마지막 단계입니다. 지속적 제공을 통해 배포 가능한 소스코드를 프로덕션 레벨로 릴리즈하는 것을 의미합니다.

실제 사례에서 지속적 배포는 개발자가 애플리케이션을 수정한 뒤 몇 분 이내에 애플리케이션을 자동으로 실행할 수 있는 것을 의미합니다.

CD를 하면 뭐가 좋은가요?

개발부터 배포까지 과정이 번거롭지 않고 간소화 되기 때문에 사용자 피드백을 빠르게 반영할 수 있습니다.
- 장애 대응이 빨라집니다. 릴리즈를 했는데 굉장히 크리티컬한 이슈가 발견되었을 때, 개발부터 배포까지의 과정이 복잡하면 반영에 오래걸리게 됩니다.
만약, 로드밸런서로 수십대의 서버를 동시에 운용한다면?
- 자동화를 하지않으면 직접 서버에 들어가서 일일이 실행해야하기 때문에 하루종일 배포를 할 수도 있습니다.

출처: https://minz.dev/18?category=850293 [MinJunKweon 개발 블로그]

적용

지속적 통합, 지속적 배포를 프로젝트에 적용시켜 통합과 배포를 자동화시켜보도록 하겠습니다.

CI 도구를 도입할 것이나 사실 정확히 CI를 하고 있지는 않습니다. 왜냐하면 CI에 대한 4가지 규칙 중 테스트 자동화에 대한 내용이 충족되지 않았기 때문입니다. 정확한 CI를 하고 싶은 경우 견고한 소프트웨어를 위한 테스트 코드를 작성해주세요.

마틴 파울러 CI 4가지 규칙

모든 소스 코드가 실행되고 누구든 현재 소스에 접근할 수 있는 단일 지점을 유지할 것
빌드 프로세스를 자동화해서 누구든 소스로부터 시스템을 빌드하는 단일 명령어를 사용할 수 있게 할 것
테스팅 자동화를 단일 명령어로 실행해 시스템에 대한 건전한 테스트 수트를 실행할 수 있게 할 것
누구나 현재 실행 파일을 얻으면 지금까지 가장 완전한 실행 파일을 얻었다는 확신을 하게 할 것

Travis Ci 설정

Travis는 깃허브에서 제공하는 CI 서비스입니다. public repository에 한해 무료로 제공됩니다.

https://travis-ci.org/ 로 들어갑니다.

Travis CI - Test and Deploy Your Code with Confidence

travis-ci.org

travis는 깃허브에서 제공하는 서비스로 깃허브 아이디로 연동가능합니다. 깃 허브 아이디로 로그인 한 뒤 오른쪽 위 메뉴바에서 Settings를 클릭해 들어갑니다.

깃허브에 등록된 repository 들 중 travis 연동을 원하는 프로젝트를 클릭합니다.

해당 Repository를 활성화시킵니다. 다음과 같이 빌드 히스토리 페이지가 나옵니다. travis 웹 사이트에서 설정은 이것으로 끝입니다. 나머지 설정은 프로젝트에서 진행합니다.

프로젝트 설정

프로젝트 root 디렉토리 아래에 .travis.yml 파일을 생성합니다.(build.gradle.kts 와 같은 위치)

tavis가 시작 시 해당 파일을 읽어드립니다.

.travis.yml

다음과 같이 설정합니다.

language
- 저는 kotlin을 사용했으므로 koltin이라고 명시하였으나 다른 언어를 사용한 경우 해당 언어를 입력해주세요.
사용한 jdk를 명시합니다.
branches
- travis CI를 수행할 github branch를 설정합니다. 저는 오직 master branch에 푸쉬될 경우에만 수행하도록 설정하였습니다.
cache
- 캐시 디렉토리를 설정합니다. 같은 의존성을 받을 경우를 방지합니다.
script
- master branch에 푸쉬됐을 경우 실행하는 스크립트입니다.
notifications
- 푸쉬 되었을 경우 이메일로 알림이 오도록 하는 설정입니다. recipients:에 본인의 이메일을 입력해주세요.

위와 같이 설정을 마쳤으면 master branch로 푸쉬해보세요.

그 다음 travis 저장소 페이지로 이동하면 현재 상태를 알 수 있습니다.

빌드가 성공하면 우측 위에 pass로 나타납니다. 마찬가지로 이메일을 확인해보면 다음과 같이 메일이 전달되었을 것입니다.

Travis + S3 연동

앞서 Travis CI를 실행하여 jar 파일을 생성했습니다. 이 생성된 jar 파일을 배포하기 위해 AWS Code Deploy 서비스를 이용합니다. 하지만 AWS Code Deploy에는 저장 기능이 따로 없기에 S3에 jar 파일을 저장하고 이 파일을 AWS Code Deploy가 가져갈 수 있게끔 하겠습니다.

따라서 우선 AWS에 접근 관련 설정부터 진행하겠습니다.

IAM

AWS에서 제공하는 서비스는 외부 서비스가 접근할 수가 없습니다. 만약 접근하고자 할 경우에는 접근 권한을 부여 받아야합니다. 이 때 인증과 권한 부여와 같은 기능을 하는 서비스가 바로 IAM(Identity and Access Management) 입니다.

AWS 콘솔에 들어가 IAM을 검색하고 들어갑니다. 해당 페이지에서 사용자 -> 사용자 추가를 클릭해주세요.

생성할 사용자 이름을 입력하고 프로그래밍 방식 액세스 유형을 선택해주세요.

다음으로 권한을 설정합니다.

저는 기존 정책 직접 연결을 통해 AmazonS3FullAccess, AWSCodeDeployFullAccess을 연결하겠습니다.

다음으로 넘어가 태그를 설정해주세요. name : "본인 설정 이름" 으로 설정합니다.

마지막으로 검토 한번 하고 사용자를 생성해줍니다.

생성하고 나면 Access ID와 Secret 키가 나타납니다. 이 키를 통해 Travis CI를 등록하겠습니다.

키 등록

travis 페이지로 돌아가 repository 설정에서 아래로 내려가보면 다음과 같이 환경변수를 설정하는 칸이 있습니다. 해당 칸에 위에 Access ID와 Secret key를 등록합니다.

이제 위 등록한 변수들을 .travis.yml 에서 사용가능합니다.

S3 생성

이제 S3 서버를 만들겠습니다. S3 서버란 Simple Storage Service의 줄임말로 파일을 관리하는 서버입니다. 이 S3 서버에 Travis CI가 생성한 빌드파일이 저장되도록 하겠습니다.

AWS 콘솔에서 S3를 검색해 S3 페이지로 입장해주세요.

버킷 생성을 클릭해 다음과 같이 버킷 이름을 작성해주세요.

옵션은 구성할 것이 없으니 바로 권한 설정으로 넘어가 퍼블릭 액세스 차단에 체크를 해주세요. 퍼블릭을 열어둘 경우 빌드된 파일이 탈취되어 중요한 정보들이 모두 탈취될 수 있습니다. 해당 옵션을 활성화해도 IAM 사용자로 발급받은 키를 사용할 수 있어 접근 가능하니 걱정 안하셔도됩니다.

모두 완료한 다음 아래와 같이 버킷이 생성되면 S3 버킷이 성공적으로 완성되었습니다.

.travis.yml 변경

이제 프로젝트에서 S3 서버에 연동할 수 있도록 .travis.yml을 다음과 같이 수정합니다.

before_deploy

before_deploy
- deploy 되기 전에 실행합니다.
zip -r springboot2-davinci-webservice : springboot2-davnici-webservice라는 이름으로 파일을 압축합니다.
mkdir -p deploy : 현재 프로세스가 실행되고 있는 지점에 deploy 파일을 생성합니다.
mv
- zip 파일을 뒤에 오는 인자의 경로로 이동시킵니다.

deploy

deploy
- 외부 서비스와 연동될 행위를 선언합니다.
travis 환경 변수에 입력했던 key들을 변수로 사용하여 access key를 할당합니다.
bucket
- S3에 생성한 버켓 이름을 입력해줍니다.
skip_cleanup
- 빌드 결과물을 삭제하지 않도록 합니다.
acl
- zip 파일에 대한 접근을 설정합니다.
local_dir
- 해당 위치 파일을 s3로 전송합니다.

이제 github의 master branch로 푸쉬합니다. 다음과 같이 s3 버킷에 zip 파일이 전송됩니다.

s3 bucket

CodeDeploy 연결

CodeDeploy이는 배포를 해주는 AWS 서비스입니다. EC2 인스턴스와 연결해야하므로 IAM 설정을 먼저 합니다.

IAM 콘솔로 들어가 역할 - 역할 만들기를 클릭합니다.

AWS 서비스의 EC2 인스턴스를 선택합니다.

다음으로 넘어가 아래 그림과 같이 정책을 선택합니다.

태그에 name도 추가합니다.

마지막으로 검토 후 역할을 생성합니다.

만든 역할을 EC2 인스턴스에게 부여합니다. 부여한 뒤 인스턴스 재부팅을 한번 실행해줍니다.

이제 EC2 인스턴스에 ssh 접속하여아래와 같이 설치를 진행해주세요.

성공시 download : ~~ 가 출력되어 나타납니다.

install 파일이 설치되었지만 실행 권한이 없습니다. 따라서 실행파일로 변경해주세요.

아래와 같은 명령어 입력후 The AWS ~~ 가 출력되면 제대로 실행되고 있는 겁니다!

이제 다시 AWS 콘솔로 돌아가 CodeDeploy 를 검색해 해당 페이지로 들어가세요. 그 다음 애플리케이션 - 애플리케이션 생성 버튼을 클릭해 애플리케이션을 생성하도록 합니다.

아래와 같이 이름을 지어주고 컴퓨팅 플랫폼을 EC2/온프레미스로 설정해주세요.

생성한 뒤 페이지 하단에 배포 그룹 생성을 눌러주세요.

아까 만든 역할을 부여하고 현재 위치 배포 유형을 선택해주세요. EC2 인스턴스가 하나밖에 없으므로 괜찮습니다. 만약 두 개 이상이라면 블루/그린을 선택해주세요.

환경 구성에서는 EC2 인스턴스를 선택하고 등록한 태그를 입력해주세요.

마지막으로 배포 설정을 아래와 같이 설정하면 끝입니다! 서버가 1대이니 전체 배포 옵션을 선택합니다.

Travis Ci, S3, CodeDeploy 연동

앞서 CodeDeploy와 EC2 인스턴스를 연결했으니 이제는 Travis, S3, CodeDeploy를 연결하면 됩니다.

우선 EC2 서버에 접속해서 빌드된 Zip 파일을 저장할 디렉토리를 생성해주세요.

이제 프로젝트 파일로 돌아와 appspec.yml을 .travis.yml과 같은 위치에 생성해주세요. appspec.yml은 codeDeploy 설정 파일입니다.

아래와 같이 입력해주세요.

version
- CodeDeploy 버전입니다.
files
- - source: / 전체 파일 선택을 의미합니다.
- destination:파일이 저장될 위치입니다.
- overwrite: 파일이 이미 존재할 경우 덮어씁니다.

아래 설정을 .travis.yml에 추가해주세요. S3에서 jar 파일을 가져와 배포할 배포 그룹과 애플리케이션을 선택해 Codeploy에 배포 요청을 합니다.

성공적으로 배포 성공했을 경우 codedeploy 페이지에 아래와 같이 나타납니다.

JAR 배포

빌드 파일을 만들고 EC2 서버로 배포까지 했으니 이제 새로 빌드된 파일을 실행시키도록 스크립트를 변경해줍니다.

프로젝트로 들어가 scripts/deploy.sh를 아래와 같이 생성해줍니다.

생성한 뒤 .travis.yml을 아래와 같이 변경해줍니다. (배포 시 실행 파일 외 파일은 필요없지만 travis는 파일 하나만 s3로 전송하지 못합니다. 단지 디렉토리 단위로 전송할 뿐입니다. 따라서 필요한 파일만 따로 뽑아내 압축한 다음 s3로 전송해줍니다.)

마지막으로 appspec.yml을 변경해줍니다. ec2 서버로 넘겨준 파일을 ec2-user 권한을 가지도록 설정해줍니다.

그리고 배포시 ec2-user의 권한으로 deploy.sh를 실행하도록 합니다.

이 후 master branch에 push하거나 PR을 보내면 빌드와 배포가 자동으로 이뤄지고 아래와 같이 빌드, 배포가 자동적으로 이루워진 것을 확인할 수 있습니다.

Travis 홈페이지

travis

AWS codeDeploy 배포

codedeploy

외부에서 접근

외부 접근

reference

출처: https://minz.dev/18?category=850293 [MinJunKweon 개발 블로그]

[CI/CD] 개발부터 배포까지 자동화 - 01 개요

계기 이번에 정부에서 공적마스크 5부제를 시행하면서 판매처(약국, 우체국, 농협 하나로마트)의 재고현황을 알 수 있는 공공 API가 생겼습니다. 예상대로 공공 API를 활용해 재고현황을 알려주는

minz.dev

https://wotjd.github.io/2019/06/blogging-hugo-%EB%A1%9C-github-%EB%B8%94%EB%A1%9C%EA%B7%B8-%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0-5.-travis-ci-%EC%97%B0%EB%8F%99/

[Blogging] Hugo 로 github 블로그 시작하기 - 5. Travis CI 연동

Hosting Blog via Github Pages with Hugo on Mac, 맥에서 Hugo로 Github Pages에 블로그 호스팅하기 Git에 대한 충분한 지식이 있다는 전제하에 적은 문서이다. Travis CI 연동 Travis CI는 지속적 통합(Continuous Integration,

wotjd.github.io

스프링 부트와 AWS로 혼자 구현하는 웹 서비스

[백준] 다익스트라 (1261번)

도라지보다더덕 — Wed, 2 Sep 2020 18:58:30 +0900

https://www.acmicpc.net/problem/1261

1261번: 알고스팟

첫째 줄에 미로의 크기를 나타내는 가로 크기 M, 세로 크기 N (1 ≤ N, M ≤ 100)이 주어진다. 다음 N개의 줄에는 미로의 상태를 나타내는 숫자 0과 1이 주어진다. 0은 빈 방을 의미하고, 1은 벽을 의미

www.acmicpc.net

다익스트라

다익스트라 알고리즘은 그래프에서 간선 비용이 0 또는 양수일 때 그리고 시작 지점이 주어졌을 때 최소 비용 거리를 찾기에 유용한 알고리즘입니다.

원리는 간단합니다. ~~(하지만 까먹습니다.)~~

1. 현재 노드에서 이동할 수 있는 후보 노드들을 조건을 따져 등록합니다.

2. 후보 노드들 중 비용이 가장 적은 노드로 이동합니다. (따라서 heap queue가 유용합니다)

3. current 노드가 이미 최소 비용이 아닐 경우는 패스합니다.

4. 위 과정을 반복합니다.

다음은 문제 풀이 코드입니다.

import sys
import heapq

m, n= map(int, sys.stdin.readline().split())

INF = int(1e9)

board = []

for _ in range(n):
    row = list(map(int, list(sys.stdin.readline().rstrip())))
    board.append(row)

dx = [-1, 1, 0 ,0]
dy = [0, 0, -1, 1]

distance = [[INF for _ in range(m)] for _ in range(n)]	# 비용

q = [(0, 0, 0)]         # (w, x, y)

heapq.heapify(q)
distance[0][0] = 0
									# (1)
while q:
    current = heapq.heappop(q)

    w, x, y = current[0], current[1], current[2]

    if w > distance[x][y]:		# (2)
        continue

    for i in range(4):
        nx = x + dx[i]
        ny = y + dy[i]

        if nx < 0 or nx >= n or ny < 0 or ny >= m:		#(3)
            continue

        d = distance[x][y] + board[nx][ny]

        if d < distance[nx][ny]:			#(4)
            distance[nx][ny] = d
            heapq.heappush(q, (d,nx,ny))
            
print(distance[n-1][m-1])

#(1) : 번호의 위 쪽은 초기 세팅입니다. 시작지점이 (1, 1) 이므로 (0, 0) 으로 설정하고 자기 자신으로 가는 비용은 0이므로 0으로 설정해줍니다.

#(2) : current는 현재 노드를 의미합니다. 현재 노드에 오기 전에 다른 노드에서 비용을 업데이트 했을 경우를 체크해줍니다. (만약 다른 노드에서 이미 더 적은 비용으로 현재 노드를 방문했다면 현재 노드를 확인하지 않습니다.)

#(3) : nx는 다음에 갈 후보 노드입니다. 다음 노드가 index를 벗어나지 않도록 합니다.

#(4) : d는 현재 노드에서 다음 노드를 갈 때 비용을 말합니다. distance는 실제로 이동했을 때 최소 비용을 의미합니다. 따라서 현재 노드에서 다음 노드로 가는 비용이 최소 비용보다 적을 경우에 큐에 push 합니다.

만약 최소 비용보다 적을 경우 distance를 업데이트 해주고 큐에 push 해줍니다.

EC2에 배포하기

도라지보다더덕 — Tue, 1 Sep 2020 17:57:41 +0900

AWS EC2와 RDS 서버 생성과 기본 설정을 마치고 실제 서버에 저의 프로젝트를 배포하겠습니다.

전체적인 순서는 이렇습니다.

1. Github에서 AWS 서버로 코드를 가지고 옵니다.

2. gradle을 이용하여 build하고 jar 파일을 생성합니다.

3. jar파일을 실행합니다.

처음 서버를 실행했을 경우 Git이 설치되어있지않습니다. 따라서 git을 설치하고 github에 올라간 코드의 master branch를 clone하여 가지고 옵니다. clone한 프로젝트 디렉토리에 들어가

./gradlew test를 실행하여 코드가 제대로 수행하는 지 확인합니다.

(현재 EC2 서버에는 gradle이 설치되어있지 않지만 ./gradlew 가 실행됩니다. 이것이 가능한 이유는 프로젝트에 포함된 gradlew라는 파일 때문입니다. gradlew는 그레들이 설치되어있지 않는 환경, 버전이 다른 환경에서 해당 프로젝트에 한해서 gradle 명령어가 실행되도록 해주는 wrapper 파일입니다.)

그 이후 위 과정을 수행하는 스크립트를 실행하면됩니다.

하지만 실제로 매번 배포 시 마다 스크립트를 일일이 작성하기가 어렵습니다. 따라서 쉘 스크립트를 작성하여 실행하도록 하겠습니다.

우선 스크립트를 작성할 deploy.sh 파일을 생성합니다. 확장자 .sh는 쉘 스크립트를 의미합니다.

deploy.sh

1.REPOSITORY, PROJECT_NAME 은 변수입니다. 쉘에서는 타입없이 변수를 선언합니다. 그리고 사용할 때 ($변수명)을 이용해 사용합니다.

2. cd: change directory, 현재 디렉토리를 변경해주는 명령어입니다.

3. echo: 터미널에 argument를 출력해줍니다.

4. ./gradlew build: 프로젝트를 빌드하여 실행파일로 만들어줍니다.

5. CURRENT_PID=$(pgrep -f ${PROJECT_NAME}*.jar) : pgrep은 프로세스의 id만 가져와줍니다. -f 옵션은 프로세스 이름으로 프로세스를 찾습니다.

6. if-else: 프로세스가 구동 중일 경우 process kill을 해줍니다.

7. JAR_NAME=$(ls -tr $REPOSITORY/ | grep *.jar | tail -n 1) : REPOSITORY 디렉토리에 존재하는 파일들을 시간 순으로 나열해줍니다. 실행 결과를 |(pipe)를 통해 전달해주고 grep 명령어를 통해 확장자가 .jar인 파일만 가지고 옵니다. 이 실행결과의 마지막 줄에 있는 파일을 JAR_NAME 변수에 저장합니다 (마지막으로 빌드된 파일을 얻기 위해)

8. nohup : nohup은 no hangups의 줄임말인 명령어입니다. 해당 명령어는 프로세스를 데몬 형태로 실행시켜줍니다. 즉, 터미널이 끊겨도 실행되도록 하는 명령어입니다.

9. java -jar를 통해 실행 파이를 실행시켜줍니다.

10. 2>&1 은 에러를 출력하는 명령어입니다. (0 입력, 1 출력, 2 에러) 마지막에 붙어있는 &의미는 백그라운드로 실행시키라는 의미입니다.

deploy.sh 를 생성했으면 해당 파일에 실행권한을 줍니다.

실행권한을 준 뒤 실행시키면 다음과 같이 실행됩니다.

실행이 제대로 수행되었는지 보려면 nohup.out 파일을 보면 됩니다. (nohup.out 파일은 애플리케이션의 모든 출력을 가지고 있습니다.)

cat nohup.out

애플리케이션이 제대로 수행되었습니다!

다음은 데이터베이스를 설정해주어야합니다. 기존의 프로젝트는 인메모리형 h2 디비를 사용하고 있었습니다. 하지만 RDS 서버를 이용해 MariaDB를 사용하도록 변경해주어야 실제 배포 시 데이터베이스를 관리할 수 있습니다.

MariaDB를 사용하기 위해 해야할 기본적인 설정은 아래와 같습니다.

테이블 생성
프로젝트 설정
EC2 설정

1. 테이블 설정

테이블 생성같은 경우는 h2 디비를 사용할 경우 자동으로 생성해주고 드랍해주었지만 MariaDB에서는 실제 배포되는 디비기 때문에 직접 쿼리를 사용해 테이블을 생성해주어야합니다.

resource에 application.properties에서

spring.jpa.properties.show_sql=true

spring.jpa.properties.hibernate.format_sql=true

로 설정해주세요. sql문을 mysql 포맷으로 보여주는 설정입니다. 그 후 프로젝트를 실행할 경우 나오는 쿼리를 이용해 RDS 서버에 테이블을 생성해주세요.

2. 프로젝트 설정

프로젝트 설정같은 경우는 MariaDB 드라이버와 디비에 접근하기위한 datasource를 설정하기 위해 꼭 필요합니다. 우선 gradle에서 MariaDB 드라이버를 가져와주세요.

resource 디렉토리에 application-real.properties를 생성한 뒤 아래와 같이 설정해주세요. (application.properties 파일의 -XX를 형태의 이름을 사용할 경우 profile=XX인 환경에서 실행되는 설정파일이라는 뜻입니다. )

위 설정을 마쳤으면 github로 push 해주세요.

3. EC2 설정

마지막으로 EC2 설정입니다.

RDS에 접근하는 정보는 보호되어야하므로 설정파일을 EC2 서버에 생성하여 둡니다. 프로젝트 디렉토리에 application-real-db.properties를 생성해주세요. (profile=real인 환경이 실행될 때 위 application-real.properties 설정파일에서 real-db를 include 했으므로 함께 실행됩니다.)

application-real-db.properties

spring.jpa.hibernate.ddl-auto=none			
spring.datasource.url=jdbc:mariadb://rds주소:포트명(default: 3306)/database이름
spring.datasource.username=db계정
spring.datasource.password=db계정 비밀번호
spring.datasource.driver-class-name=org.mariadb.jdbc.Driver

spring.jpa.hibernate.ddl-auto=none : jpa 테이블 자동생성 옵션을 생성되지않음으로 변경합니다.

datasource.**: 데이터베이스에 접근을 위한 설정들입니다.

마지막으로 profile=real로 실행되도록 deploy.sh 를 변경합니다.

nohup 부분을 아래와 같이 변경해주세요. (\는 줄바꿈을 의미합니다. 줄을 바꾸지 않으면 오류가 발생하니 주의해주세요)

-Dspring.config.location 옵션은 설정파일의 위치를 지정해줍니다. classpath가 붙으면 jar파일의 설정위치를 기본 경로로 파일이 지정됩니다. 외부경로에 있는 properties는 절대경로로 지정해서 설정해줍니다.

-Dspring.profiles.active=real은 profile=real을 활성화시켜 실행시켜줍니다.

저장한 뒤

./deploy.sh를 실행하면 성공적으로 연결됩니다. 이제 내 컴퓨터의 로컬환경에서 프로젝트에 접근해봅시다.

AWS EC2 콘솔에 들어가 퍼블릭 DNS 주소를 복사해 브라우저 URL에 입력해봅시다.

성공적으로 배포되었습니다.

reference

스프링 부트와 AWS로 혼자 구현하는 웹 서비스

AWS RDS 사용하기

도라지보다더덕 — Fri, 28 Aug 2020 01:58:00 +0900

AWS RDS

이전에 AWS EC2 인스턴스를 생성하고 여러 설정들을 했습니다. 이제 데이터 베이스 서버를 설정할 차례입니다. 데이터 베이스 서버는 AWS 관계형 데이터 베이스 서비스인 RDS를 사용해 구축합니다. 프리티어로 사용할 경우 EC2와 마찬가지로 무료이기 때문에 학습용으로 적합합니다.

1. RDS 생성

콘솔로 로그인하여 검색창에 RDS를 검색하고 클릭하면 다음과 같은 화면이 나옵니다. 화면 아래부분에 있는 데이터베이스 생성을 클릭해주세요.

클릭하고 엔진 옵션을 보면 여러 엔진이 있습니다. 저는 MariaDB를 사용하겠습니다. 무료로 사용하기 위해 프리 티어로 선택해주세요.

아래는 설정란입니다. 식별자는 본인 프로젝트 이름을 써주시고 나머지를 모두 작성하고 기억해주세요. 나중에 디비에 접속 시 필요합니다.

연결 탭에서 퍼블릭 액세스 가능에 '예'를 체크해주세요. 나중에 보안 그룹 설정에서 다시 설정할 예정입니다.

데이터 베이스 이름을 설정해주세요. 그리고 파라미터 그룹을 디폴트로 설정한 다음 데이터 베이스를 생성해주세요.

데이터 베이스를 생성했으면 몇 가지 설정을 해야합니다. 이 때 파라미터 그룹을 사용하면 쉽게 설정할 수 있습니다.

아래 세가지를 먼저 설정하겠습니다.

타임존
Character set
max connection

좌측 메뉴에서 파라미터 그룹을 클릭하고 파라미터 그룹 생성하기를 눌러주세요. 다음과 같은 화면이 나옵니다.

이 때 파라미터 그룹 패밀리는 위에서 생성한 디비 버전과 일치하게 해주세요.

생성된 파라미터 그룹을 클릭하고 편집하기를 눌러주세요. 그 후 검색창에 time_zone을 검색하시면 다음과 같이 나옵니다.

Asia/Seoul로 설정해주세요.

마찬가지로 character을 검색하시고 아래 5가지 항목을 utf8mb4로 바꿔주세요.

설정을 완료했으면 다시 데이터베이스로 돌아가 DB 파라미터 그룹을 방금 생성한 파라미터 그룹으로 설정해주세요.

적용 시 즉시 적용을 눌러 바로 적용되도록 하고 서버 재부팅을 한번 진행해 주세요.

2. 보안설정

파라미터 설정을 마쳤으면 다음은 보안그룹 설정입니다. 데이터베이스로 돌아가 아래 화면 보안그룹을 클릭해주세요.

인바운드 규칙 추가를 하여 내 iP 주소와 EC2 인스턴스의 보안그룹 Id를 추가해주세요.

(EC2 인스턴스의 보안그룹 Id를 추가해야 EC2에서 RDS로 접근 가능합니다)

3. 로컬환경에서 접속

위 과정을 모두 했으면 IDE로 돌아와 connection Test를 해봅니다.

저는 intellij 플러그인인 Database Navigator가 다운받아져있으므로 없으신 분들을 다운받은 뒤 Action 검색을 통해

Database Browser를 실행해주세요.

그 후 New Connection을 하여 MySQL로 생성해주세요. (MariaDB는 MySQL 기반이라 MySQL로 선택했습니다)

클릭 후 생성 창에서 Host에 RDS의 엔드포인트를 적고 마스터 사용자 id와 비밀번호를 적은 뒤 Test Connection을 진행해보세요.

(엔드 포인트는 RDS 세부정보에 있습니다.)

성공적으로 test connection이 연결되었다면 console을 생성해주세요.

생성한 콘솔에서 다음과 같은 쿼리를 날려줄겁니다.

use springboot2_davinci_webservice;  #데이터 베이스를 선택합니다.

show variables like 'c%'; 			#Character Set을 보여줍니다.

ALTER DATABASE springboot2_davinci_webservice		#설정이 안된 character set을 직접 변경해줍니다.
CHARACTER SET = 'utf8mb4'
COLLATE = 'utf8mb4_general_ci';

CREATE TABLE test (						#테이블 생성
    id bigint(20) NOT NULL AUTO_INCREMENT,
    content varchar(255) DEFAULT NULL,
    PRIMARY KEY (id)
) ENGINE=InnoDB;

insert into test(content) values('테스트');	#한글 입력

select * from test;						#결과 화면

다음과 같이 한글입력이 제대로 됨을 볼 수 있습니다.

4. EC2에서 RDS 접속

마지막으로 EC2 인스턴스에서 RDS로 접근해보겠습니다. 이전에 ssh로 접속했던 것처럼 접속해주시고 mysql을 설치해주세요.

설치과 완료됐으면 다음과 같이 연결을 시도해봅니다. 비밀번호를 입력하라고하면 입력해주세요.

연결 성공 시 show databases;를 통해 데이터베이스를 확인해봅시다.

성공적

reference

스프링 부트와 AWS로 혼자 구현하는 웹 서비스

AWS 사용하기

도라지보다더덕 — Wed, 26 Aug 2020 15:25:24 +0900

내가 만든 서비스를 배포(Deployment)하기 위해서는 항상 가동되고 있는 서버가 필요합니다. 일반적으로 기업들은 물리적인 회사 서버를 가지고 서비스를 외부에 제공하거나 클라우드 서비스를 이용하여 제공합니다. 하지만 저는 집 컴퓨터를 24시간 365일 켜놓고 있을 수는 없고 개인 서버 장비를 살 정도로 부유하지 않으니 클라우드를 통해 배포를 진행해보도록 하겠습니다.

그 중에서 IaaS의 대표적인 예시인 AWS EC2를 사용해보도록 하겠습니다.

1. AWS 회원가입

우선 AWS로 접속하여 계정 생성을 클릭합니다. 메일주소, 암호 계정 이름 등을 입력하고 넘어가면 다음과 같은 화면이 나옵니다.

이 때 계정 유형은 개인으로 선택하고 주소는 영문 주소를 기입합니다. (영문 주소 찾기)

다른 칸도 다 기입해주세요

모두 기입한 후 단계를 넘어가면 결제 정보를 입력하는 폼이 있습니다. Visa 카드나 Master 카드를 준비해 작성해주세요.

입력이 완료되면 본인 확인을 거치고 마지막으로 지원 플랜을 선택합니다. 저는 학습용으로 사용할 예정이니 기본 플랜으로 선택하겠습니다.

2. AWS EC2 인스턴스

위 회원가입을 모두 마치면 콘솔로 로그인하기를 클릭하여 로그인해주세요. 그리고 ec2를 검색하여 클릭하면 다음과 같은 화면을 볼 수 있습니다.

초기 리전은 미국 동부 (오하이오)로 설정되어 있습니다. 리전은 AWS 클라우드 센터의 위치를 의미합니다. 이 클라우드 센터에서 운영되는 가상머신을 사용하는 것이기에 가장 가까운 위치를 선택하는 것이 좋습니다. 현재는 서울에도 AWS의 서버가 존재하니 한국에서 클라우드를 사용 시 특별한 이유가 없으면 서울로 변경해주세요. (우측 상단에 설정있습니다.)

리전을 설정했으면 인스턴스 시작을 눌러주세요. 다음과 같은 화면이 나옵니다. 다음 화면은 아마존 머신 이미지를 선택하는 화면입니다. AMI는 EC2 인스턴스의 필요한 정보를 이미지로 만들어 둔 것입니다. 첫번째로 나온 AMI 를 선택하여 사용하겠습니다.

이미지 선택 후 다음 단계로 넘어가면 인스턴스 유형을 선택할 수 있습니다. nano, micro와 같이 뒤에 붙은 것은 사양을 의미합니다. 저는 t2.micro를 사용하겠습니다.

그 다음 단계인 3, 4 단계는 학습단계에서 특별히 설정할 것이 없으므로 넘어가겠습니다. 다음 단계는 태그 추가 단계입니다. 다음과 같은 화면이 나옵니다. 인스턴스가 여러 개가 될 경우 이름을 구별하기 위해 Name 태그를 추가하여 넣어주겠습니다.

다음 단계는 보안 그룹 구성입니다. 보안은 굉장히 중요한 사항이므로 잘 설정해야합니다. 우선 ssh로 접근하는 유형의 IP를 설정해줍시다. 어차피 pem키가 없으면 접근을 못하니 전체 IP를 허용해놓는다고 생각할 수 있습니다. 하지만 실수로라도 pem키를 노출할 경우 굉장히 위험하니 ssh 접속이 필요한 곳에서 IP를 추가하여 접속하는 것이 좋습니다. 내 IP를 선택하면 자동으로 자신의 IP가 입력됩니다. 다음은 기본포트인 8080 포트를 열어두었습니다. 8080포트를 열어두는 것은 크게 위험한 일은 아니니 전체 IP에 대한 허용을 해놓습니다.

이제 시작하기 버튼을 클릭하면 보안을 개선하라는 경고 메세지가 뜹니다. 8080 포트를 전체 IP 허용으로 해놔서 뜨는 경고 메세지이니 걱정말고 시작하기를 클릭합니다.

다음은 키 페어 생성입니다. ssh 접속 시 pem키가 필요한데 이 키를 생성해줍니다. 새 키 페어 생성을 선택한 후 키 페어 이름을 적절하게 지어주고 키 페어 다운로드를 클릭합니다.

다운로드 완료 후 인스턴스 ID를 클릭하면 EC2 인스턴스가 생성되고 실행 중인 것을 알 수 있습니다.

생성 후 그대로 사용할 수도 있지만 해당 인스턴스가 재실행될 경우 IP가 변경되어 재실행 시마다 확인해주어야 합니다. 따라서 고정 IP를 할당하는 것이 편리합니다. 왼쪽 메뉴바에서 탄력적 IP 메뉴를 선택해주세요. 그 후 우측 상단에 탄력적 IP 주소 할당을 클릭 후 새 주소를 할당합니다. 마지막으로 작업을 클릭하여 현재 EC2 인스턴스와 연결해주세요.

(EIP 생성 후 인스턴스를 연결 안할 경우 요금이 부과된다고 합니다. 따라서 인스턴스를 연결하지 않을 경우 EIP를 삭제해주세요.)

다시 인스턴스 페이지로 돌아와서 하단에 탄력적 IP가 제대로 할당되었는지 확인하세요!

3. EC2 서버 접속

AWS EC2 인스턴스로 서버를 실행했으니 로컬환경에서 접속해봅시다. 아까 다운로드 받았던 pem키를 이용하여 ssh 접속을 할 수 있습니다.

ssh -i pem키위치 접속하고자하는IP

매번 이렇게 접속하기 힘드니 ~/.ssh에 pem를 옮겨놓습니다.

mv pem키 ~/.ssh

그리고 config를 작성하여 호스트 네임을 통해 접속 가능하도록 설정해줍시다.

vi ~/.ssh/config

Host는 ssh 뒤에 입력할 호스트 이름입니다.

HostName은 위에서 할당한 EIP 입니다.

User는 접속할 유저입니다.

IdentityFile은 pem key의 위치입니다.

ssh "Host"

esc wq로 저장 후 설정한 Host의 이름을 입력합니다. 위와 같은 경우에는 springboot2-davinci-webservice입니다.

다음과 같은 화면이 출력되면서 접속이 잘 된 것을 확인할 수 있습니다.

4. AWS 설정

AWS의 생성과 ssh로 접속이 완료되었으면 이제 서버의 몇 가지 필수 설정을 해야합니다.

java 버전 설정
타임존 설정
호스트 네임 설정

java 버전 설정

AMI 1 버전으로 서버를 실행했다면 java 7 이 기본 버전으로 설정되어 있습니다. 하지만 그 상위 버전인 java 8을 사용하기 위해선 java 8을 다운로드 받은 뒤 변경해야합니다.

설치가능한 java 버전을 보면 1.8 버전이 다음과 같이 존재하므로

sudo yum install java-1.8.0-openjdk-devel.x86_64 	#설치
sudo /usr/sbin/alternatives --config java		#버전 변경

위 명령어를 통해 다운 받은 뒤 버전을 변경하면 됩니다.

저는 java 11 버전이 필요했지만 패키지에 java 11이 존재하지않았습니다. 따라서 java 11 rpm을 검색하여 다운받아 따로 설치했습니다.

타임존 변경

AWS의 기본 시간은 UTC로 설정되어있습니다. 아래 명령어를 차례로 입력해 한국 표준 시간대(KST)로 변경합니다.

호스트 네임 설정

network파일을 변경하여 hostname을 설정해줍니다.

reboot 명령어로 서버를 재부팅하면 호스트 네임이 변경돼있는 걸 확인할 수 있습니다.

마지막으로 /etc/hosts내부에 hostname을 등록해줍니다.

sudo vi /etc/hosts

제대로 등록이 되었다면 다음과 같이 curl을 이용해 요청했을 경우 연결이 거부되었다는 메세지가 뜹니다

reference

스프링 부트와 AWS로 혼자 구현하는 웹 서비스

클라우드 서비스

도라지보다더덕 — Thu, 20 Aug 2020 19:03:40 +0900

클라우드란?

클라우드 서비스란 인터넷을 통해 각종 자원(운영체제, 데이터베이스, 스토리지 .. 등)을 제공해주는 서비스를 말합니다.

Cloud

예전에는 각자의 물리적인 서버가 존재하고 직접 관리하며 프로젝트를 배포했습니다. 하지만 클라우드 서비스가 발전하면서 많은 기업들이 물리적인 서버를 관리하기 보다는 클라우드로 이전하는 것을 택하고 있습니다. 따라서 저도 클라우드를 이용하여 무중단 배포를 해보겠습니다. 클라우드를 사용하기 전에 클라우드의 몇가지 형태에 대해 알아보겠습니다.

(1) Infrastrucure as a Service(IaaS)

서버 운영하기 위해 필요한 자원, IP, 네트워크 등 여러 인프라를 제공해주는 클라우드 서비스입니다. 서버를 운용하기위해서는 물리적인 장비들이 필요한데 이를 미들웨어와 함께 묶어 추상화하여 사용자에게 제공합니다. 우리가 흔히 아는 AWS EC2, S3가 대표적인 예입니다.

(2) Platform as a Service(Paas)

서비스를 개발 시 안정된 환경(Platform)을 제공합니다. IaaS를 한번 더 추상화하여 여러 기능들이 자동화되어 있습니다. 대표적인 예로 AWS Beanstalk, Heroku가 있습니다.

(3) Software as a Service(SaaS)

클라우드 환경에서 작동하는 응용 프로그램입니다. 개발자가 아닌 일반 사용자들이 말하는 클라우드는 주로 SaaS를 뜻합니다. 대표적으로 Icloud, 구글 클라우드, 드랍박스 등이 있습니다.

저는 AWS 초보자이기 때문에 직접 하나씩 다뤄보는 것이 공부에 도움이 되므로 AWS EC2를 사용하여 배포해보도록 하겠습니다.