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

Image 와 Container 의 이해 이미지 - 컨테이너를 생성할 때 필요한 요소이며, 여러 개의 계층으로 된 바이너리 파일로 존재하며, 컨테이너를 생성하고 실행할 때 읽기 전용으로 사용된다. 컨테이너 - 이미지를 읽기 전용으로 사용하되 이미지에서 변경된 사항만 컨테이너 계층에 저장하므로 컨테이너에 무엇을 하든지 원래 이미지는 영향을 받지 않는다. Image 는 특정 Application 에 필요한 코드와 라이브러리와 의존성 등을 가진 불변( Immutable, unchangeable ) 파일이다. Image 는 read-only template 이다. 특정 시점의 가상 환경 혹은 Application 을 나타내는 일종의 스냅샷으로 이해할 수 있다. → 이러한 Docker 의 훌륭한 특징 중의 하나로, 개발자들이 안정적이고 단일한 환경에서 test 하고 실험할 수 있는 환경을 만들어 낸다. Container 는 Image 를 단지 run 한 것이다. Container 를 생성하게 되면, 불변한 Image 의 최상단에 Writable Image Layer 를 추가하여 변경이 가능하도록 한다. 이를 쉽게 이해하기 위해서 아래 이미지를 참고하면 된다. Image 와 Container 는 면밀히 관련되어 있다. Image 는 Container 없이 존재할 수 없으며, Container 는 존재하기 위해서 Image 를 run 해야 한다. 따라서, Container 는 Image 에 의존적이고, run-time 환경을 생성하기 위해서 Image 를 사용한다. Image 와 Container 의 개념은 Docker 의 근본적인 component 로써 존재한다. 정확하게 일치하는 개념은 아니지만, 객체 지향 관점에서 Docker 의 생태계를 비추어 볼 때 유사한 지점이 있다. Image 를 class 에 비유할 수 있으며, Container 를 해당 class 의 Instance 로 비추어 볼 수 있을 것 같다. Docker Engine Do...

지난 글에서는 ArrayList 를 까보면서 native 메서드에 대해 잠시 다루어보았다. 이번 글에서는 직접 HashMap 을 구현해보도록 하겠다. JDK 를 까보면서 그리고 여라 다른 블로깅을 참고하면서 내 방식으로 구현해 보았다. https://medium.com/@mr.anmolsehgal/java-hashmap-internal-implementation-21597e1efec3 https://www.devglan.com/java8/hashmap-custom-implementation-java https://d2.naver.com/helloworld/831311 우선, 핵심을 먼저 정리하고 작성해보겠다. HashMap 은 Key Value 저장소이다. 분할상환방식에 의해서 get() put() 메서드는 상수 시간의 시간복잡도 O(1) 을 가진다. HashMap 은 내부적으로 key, value 를 지닌 Node 의 배열을 가진다. Node 의 개념과 일치하는 class 는 Entry<K, V> class 이다. HashMap 은 get(), put() 메서드 호출 시  객체의 hashcode 를 통해 index 를 계산하고  Node 배열의 Node 를 배치시킨다.  그렇다면 같은 index 를 가지는 객체들은 어떻게 관리를 할까? 바로 LinkedList 를 배열의 index 마다 가지며, 2차원 형태의 테이블을 이루게 된다. 아래는 JDK 11 버전의 HashMap 을 직접 까보았다. 아래와 같이 Node 는 Map.Entry<K, V> interface 를 구현하고 있다. 그리고 필드로는 hash, key, value, 그리고 LinkedList 이기에 next 를 가진다. 여기까지가 HashMap 가장 기본적인 원리이다. 하지만 가장 큰 문제가 있다. 바로 다른 객체가 동일한 hashcode 를 가질 때 이다. 예를 들어, 아래와 같이 Developer class 를 작성했다. equals() 와 h...