기록들 https://github.com/ndgndg91

 오늘의 글은 나의 경험담을 정리하려고 한다. 무슨 경험이라고? 내가 삽질한 경험이다. 우선, 개발 환경부터 간단하게 정리해보겠다.  단일 EC2 환경이다. 아래와 같이 여러 가지 개발 툴 을 설치했다. - Jenkins (9090 port) - Tomcat (8080 port)  - Github - Maven Tomcat 에 Github 의 Spring 프로젝트를 Maven 을 이용하여 War 로 패키징하는 간단한 Deploy 방식이였다. Deploy 는 Jenkins 프리스타일 프로젝트를 사용했다. 1. Git Parameter Plugin 을 이용해서 브랜치를 선택할 수 있게 한다. 2. NodeJS Plugin 과 기존에 설치해 둔 Maven 을 이용하여 Shell Script 를 실행하여 War 패키징 및 해당 EC2 Tomcat 에 올리고 실행하게 한다. 아래는 간단한 shell script 이다.  maven PATH 를 잡아주고, 미리 설정해 둔 S3에서 properties 파일을 가져온다. 그리고 mvn 명령어를 통해서 war 로 패키징하고, 패키징 한 war 를 S3 에서 버전관리 한다. 그리고 톰캣을 우선 정지하고, 새로 패키징한 war 를 tomcat 경로에 맞게 올린다. 그리고 잠시 스레드를 5초 동안 잠재운다.  그후에 다시 톰캣을 시작한다. 이러한 과정에서 여러 브랜치를 아마 대략 70 번 (?) 정도 배포 했다.  70번 밑으로 배포는 정상적으로 배포가 잘 되었고, 테스트로 잘 할 수 있었다.  그러나 70번 정도가 넘어가자, 달콤한 404 를 맞이하게 된다. 뭐지? 왜 잘 되던게 갑자기 안될까??? 제일 짜증나는 부분이다. 삽질을 하다가 tomcat log 를 찾아봤다. /var/log/tomcat8/catalina.out 아래와 같이 ConflictingBeanDefinitionException 을 확인한다.  ConflictingBeanDefinitionEx...

 많은 사람들이 알다시피, Jenkins 는 유용한 CI / CD 오픈소스 툴이다. 온프레미스 환경 및 클라우드 환경을 넘나들며 유용하게 사용할 수 있다. Jenkins 가 제공하는 수많은 기능들이 있다. 그 수 많은 기능들 중에 이번 글에서 정리할 내용은 Publish over SSH Plugin 이다. 기존에 이미 Jenkins 는 EC2 에 설치가 되어있고 배포 대상이 되는 EC2 도 있다는 전제하에 정리해보겠다.  혹시라도 Jenkins 설치 방법이 궁금하다면 예전 글에서 정리한 것을 참고하길 바란다.  https://infondgndg91.blogspot.com/2020/06/install-jenkins-in-aws-ec2.html 이번 글에서 무엇을 정리할 것인가 나열하겠다. 1. Github 에서 Source code 를 땡겨온다. ( 이번 글에서 Github 설정은 다루지 않는다. ) 2. Gradle 로 Spring boot project 를 jar 로 빌드한다. ( 이번 글에서 Gradle 설정은 다루지 않는다. ) 3. 빌드한 jar 를 Publish over SSH 플러그인을 통해서 Deploy EC2 에 전송한다. 4. Deploy EC2 에 있는 shell script 를 Jenkins EC2 에서 원격 호출한다. 우선, Publish over SSH 플러그인 부터 설치해보자. 아래는 해당 플러그인 공식 Documentation 이다. https://plugins.jenkins.io/publish-over-ssh/ admin 으로 들어가든, 권한이 있는 계정으로 들어가자. Jenkins 관리로 들어가자. 그리고, 플러그인 관리로 들어가자. 나는 이미 설치를 했기 때문에, 설치된 플러그인 목록에서 검색을 통해서 확인할 수 있다. 설치가 되지 않은 상태라면, 설치 가능 목록에서 Publish over SSH 검색 후 설치하면 된다. 플러그인 설치가 되었다면, 이제 시스템 설정으로 들어가자.  들어가서, 스...

 요즘에, AWS 를 사용하면서, 여러가지 Resource 들을 다루어 보고 있다. 이러한 과정속에 다루는 Resource 가 많아질수록 또는 여러사람들이 Resource 를 추가하고 삭제하고 변경하는 과정에서 추적이 쉽지 않고 관리가 어려워지는 것을 느꼈다. AWS 에서 기본적으로 제공하는 서비스인 CloudFormation 도 있고, 최근에는 CDK 를 지원하고 있기도 하고 이외에도 Ansible, Chef, Puppet 등 다양한 IaC 도구들이 있다는 것을 알지만, 나는 아직 초짜라서 이 모든것을 경험해보진 못했다. https://aws.amazon.com/ko/about-aws/whats-new/2019/07/the-aws-cloud-development-kit-aws-cdk-is-now-generally-available1/ 요즘 새롭게 꽂혀서 Terraform 을 이것저것 만져보고 있다. 새롭게 Infrastructure 를 구축할 때는 실습해보면서 감을 익히는 정도인데, 문득 기존에 존재하는 수많은 Resource 들을 Terraform 으로 쉽게 관리할 수 있는 방법은 없을까? 라는 의문점이 생겼다. existing AWS Resource import Terraform 라는 키워드로 구글링을 하는 과정에서 Medium 에서 블로깅한 내용을 발견했다. https://medium.com/@yoga055/importing-existing-aws-resources-to-terraform-using-terraforming-3221b26e015 해당 내용을 보고, 오! terraforming 역시, 누군가가 괜찮은걸 이미 만들어 놨군! ㅋㅋ https://github.com/dtan4/terraforming 사용법도 정말 간단하다. 우선 Mac OS 기준으로 사용법을 정리하고 마치겠다. 먼저 필요한건 AWS CLI 이다. AWS CLI 설치 방법은 간단하다. 아래 링크로 들어가서 인스톨러 다운받고 설치하면 된다. https://docs.aws.am...

IP Address IP 주소는 Network Address 와 Host Address 로 구성되어 있으며, 32 bit로 4 byte 데이터이다. 예를들어, 10.11.12.13 이라는 IP Address 는 아래와 같이 구성되어있다. 10.11.12 .0 → 00001010.00001011.00001100. ( Network Address ) 0.0.0. 13 → 00001101 (Host Address) 전체 IP Address 를 32비트로 보면 아래와 같이 나타낼 수 있다. 10.11.12.13 → 00001010.00001011.00001100.00001101 하나의 8비트 섹션을 옥텟(octet)이라 부른다. Subnet Mask TCP/IP 프로토콜에 의해 Host 가 로컬 서브넷에 있는지 아니면 원격 네트워크에 있는지를 확인하는 데 사용된다. 10.11.12.13 → 00001010.00001011.00001100.00001101 255.255.255.0 → 11111111.11111111.11111111.00000000 이는 10.11.12.0/24 를 의미한다. 24 는 24 bit 를 의미하는데 앞서 255.255.255.0 은 8bit.8bit.8bit.0 을 의미한다. 따라서, 8bit * 3 = 24bit 을 의미하며, 8bit 이라는 의미는 더이상 해당 옥텟에 host 부여가 불가능하다는 의미이다. 따라서 해당 네트워크의 호스트가 부여가능한 IP range 는 10.11.12.1 ~ 10.11.12.254 범위를 의미한다. 여기서, 10.11.12.0 과 10.11.12.255 는 포함되지 않는다. 호스트 번호 부분의 비트 값이 모두 0 또는 1인 경우는 특별한 의미를 가진다. 모두 0 → 서브넷 자체를 가리킨다. (10.11.12.0 → 00001010.00001011.00001100. 00000000 모두 1 → 서브넷에 있는 기기 전체에 패킷을 보내는 브로드캐스트  를 나타낸다. (10.11.12.255 →...

 지난 글  https://infondgndg91.blogspot.com/2020/08/aws-vpc.html  에서 서울 리전에 VPC 및 서브넷을 생성해 보았다. 이전 글에서 만들었던 VPC 를 기준으로 인터넷 게이트웨이와 NAT 게이트웨이, 라우팅 테이블, 탄력적 IP, 네트워크 ACL, 보안 그룹을 실습 하면서 아래와 같이 정리해보겠다. 우선, 라우팅 테이블은 VPC 생성 시 자동으로 생성 된다. 기본 VPC 를 통해 확인이 가능하다. 먼저, 기본 VPC 기본 VPC 에 매핑 된 라우팅 테이블 기본 VPC 의 CIDR 블록을 172.31.0.0/16 의 대상은 local 로 기본 VPC 에 속한 모든 Subnet 에 대하여 라우팅을 제어하는 역할은 한다.  그리고 기본 VPC 가 아닌 새로 VPC 를 생성하는 것과의 차이는 바로 Internet Gateway. 기본 VPC 에는  Routing table 에 자동으로 Internet Gateway 가 붙어 있다.  Internet Gateway 가 하는 역할은 VPC 내의 Instance 와 인터넷 간의 통신이 가능하게 만들어 준다. 하지만 기본 VPC 가 아닌 새롭게 생성한 VPC 의 경우에는 Internet Gateway 가 자동으로 생성되지 않고 라우팅 테이블에 추가 되지 않기에, 새롭게 Internet Gateway 를 생성해주고 새로 생성한 VPC 라우팅 테이블에 추가해줘야 인터넷과 새로 생성한 VPC 내의 Instance 간의 통신이 가능하게 된다. 아래와 같이 Internet Gateway 를 생성하고,  새로 생성한 giri-vpc 에 attach 했다. Destination 0.0.0.0/0 Target 은 새로 생성한 Internet Gateway 가 새로 생선한 giri-vpc 라우팅 테이블에 추가 되었다.  여기서 중요한 점은 이전 글에서 생성한 Public Subnet 과  Private Subnet 에...

 이번글에서는 AWS 사용하면서, 뼈대가 되는 VPC 를 직접 생성 하면서 정리를 해보겠다. 리전은 한국사람이니 서울을 선택했다. Region 별로 비용의 차이가 있다고 하는데, 어차피 당장 서비스를 올릴게 아니라서 비용 따위는 생각하지 않는다. 그럼 시작해보자. 우선, VPC 를 생성하기에 앞서 가장 기본적인 주의사항에 대해서 짚어보자. CIDR 블록 설정 시 주의사항 → 사설 ip 대역만 설정한다. 공인 ip 대역을 설정하게 될 경우 VPC 내부망과 겹치는 공인 IP 는 인터넷 즉, VPC 외부에서 접속이 불가능하게 된다. 따라서 인터넷 연결이 필요한 경우에는 반드시 사설 IP 대역을 사용해야 한다. 10.0.0.0 ~ 10.255.255.255  172.16.0.0 ~ 172.31.255.255  192.168.0.0 ~ 192.168.255.255 아래와 같이 giri-vpc 라는 이름의 vpc 를 생성했다. CIDR 블록은 10.255.0.0/16 로 설정했다. VPC 만 가지고 할 수 있는 것은 아무것도 없다. VPC 는 availity zone 들의 논리적인 묶음이라고 보면 된다 따라서 VPC 를 생성 하면서 할당한, CIDR 블록을 다시 Subnet 단위로 나눈다. 하나의 VPC 는 N개의 Subnet 을 가질 수 있다. Subnet 의 CIDR 블록을 작게 잡을수록 VPC 를 많은 Subnet 으로 나눌 수 있다. 일반적으로 Region 의 가용 영역의 개수 만큼 Subnet 을 구성하여, 재해에 대응하는 방법을 취하고 있다. 서울 리전 (ap-northeast-2a) 의 경우에 가용 영역은 총 4개이다. 앞서 생성한 giri-vpc 를 4개의 subnet 으로 구성할 것이다. 여기서 한 가지 주의할 점! 각 서브넷의 0, 1, 2, 3 과 255 주소는 instance 에 할당할 수 없다. 아래의 문서를 참고하면 된다. https://docs.aws.amazon.com/vpc/latest/userguide/VP...

네트워크 드라이버 bridge host none container overlay 아무런 설정을 하지 않고 컨테이너를 생성할 경우 기본적으로 docker0 bridge 사용한다. veth 인터페이스는 각 Container 마다 생성된다. docker0 인터페이스와 Binding 되어 호스트의 eh0 인터페이스와 이어지며 외부와 통신이 가능하게 된다. Bridge Network docker network ls 명령어와 docker network inspect bridge 명렁어를 통해서 확인하기 Gateway 와 Subnet 을 확인할 수 있다. 그렇다면, docker network create --driver bridge {name} 명령어를 통해서 사용자 정의 브리지를 생성하고 적용해보자. 기본 bridge 와는 다르게 172.18.x.x 대역으로 Gateway 와 Subnet 이 잡혀있다. 사용자 정의 브리지를 통해서 컨테이너를 생성해보자. docker run -it 옵션을 통해서 생성한 컨테이너에 attach 모드로 들어간다. --net 옵션을 통해서 사용자 정의 브리지를 설정한다. 생성한 ubuntu 컨테이너안에서 ifconfig 명령어를 통해서 172.18.0.2 를 할당받은 것을 확인할 수 있다. 또한 임의로 Subnet, Gateway, Ip range 를 아래와 같이 설정할 수 있다. --subnet 옵션과 --ip-range 옵션 그리고 --gateway 옵션을 통해서 가능하다. --net-alias 옵션을 통해서 사용자 정의 브리지에 별칭을 부여할 수 있다. ip 할당은 라운드 로빈방식이다. 각각의 컨테이너에 172.18.0.2 ~ 4 까지 할당한 것을 확인할 수 있다. Host Network 호스트 네트워크 환경을 컨테이너에서 동일하게 사용한다. 컨테이너 내부의 Application 을 별도의 port forwarding 없이 바로 서비스가 가능하다. None Network 아무런 네트워크도 사용하지 않는 것. 컨테이너 외부와...