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

 요즘에, 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 아무런 네트워크도 사용하지 않는 것. 컨테이너 외부와...