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

네트워크 드라이버 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...

요즘, 그동안 기본기를 너무 챙기지 않고 프레임 워크와 아키텍쳐에 빠졌나 싶어서, 자료구조와 알고리즘을 다시 보고 있다가, 실질적으로 jdk 의 List 구현체인 ArrayList 를 까서 보았다. 그러다가 흥미로운 것을 보게되었고, 실질적으로 jdk 를 까보는 것도 재미가 있어서 블로깅을 해본다. 다들 알겠지만, ArrayList 는 말 그대로 내부적으로 data 를 저장하는 배열(array) 을 가지고 있다. 자료구조와 알고리즘 공부를 하게되면, 기본중의 기본인 ArrayList 와 LinkedList 의 비교를 하게 된다. ArrayList 의 add() 메서드는 끝에 집어 넣을 때 O(1) 상수 시간이고, 처음에 집어 넣을 때와 일반적인 상황에서 O(n) 으로 선형 시간이 된다.  remove() 메서드도 배열의   제일 마지막을 지울 경우 O(1) 상수 시간이고, 처음을 지울 때와 일반적인 상황에서는 O(n) 으로 선형 시간이 된다. 배열을 내부적으로 가지고 있기 때문에, 당연하게 시작 혹은 중간에 data 를 삽입하게 되면 삽입 지점 index 에 있던 원래 있던 data 부터 배열의 끝까지의 모든 데이터들을 다음 index 공간( 오른쪽 )으로 Shift 연산을 해야 한다. 즉 해당 index 지점부터 배열의 끝까지 순회 하면서 오른쪽으로 한 칸 씩 밀어주게 된다. 반대로 remove 삭제의 경우에도, 시작 혹은 중간에 data 를 지우려고 하면 해당 지점 index 한칸 뒤에 있는 지점부터 배열의 끝까지의 data 들을 한칸 씩 모두 왼쪽으로 Shift 연산을 해야 한다. 즉 해당 index 다음 지점부터 배열의 끝까지 순회 하면서 왼쪽으로 한 칸 씩 밀어주게 된다. 이미지 제작의 귀찮음으로 아래 사이트의 이미지를 사용했다. https://cloudstudying.kr/lectures/138 그래서 Shift 연산이 필요하기 때문에 선형 시간 O(n) 의 시간 복잡도를 가진다. 자, 그렇다면 이제 JDK 를 까보자....

이번 글에서는 spring boot admin 에 대해 다루어 보겠다. spring boot admin 은 spring boot 어플리케이션들을 모니터링하고 관리하기 위한 웹 어플리케이션이다. 각각의 어플리케이션은 client 로 간주되고 admin server 에 등록된다. spring boot actuator endpoints 만 열어두면 알아서 설정이 된다. 정말 쉽고 간편하다. https://github.com/codecentric/spring-boot-admin https://www.baeldung.com/spring-boot-admin 정리해볼 내용은 아래와 같다. 1. spring boot admin client 1개 구현 (with spring boot actuator) 2. spring boot admin server 1개 구현 https://github.com/ndgndg91/actuator-boot-admin spring boot admin client 는 임의로 api 하나를 가진 api server application 이다. 이 application 은 spring boot actuator 설정을 통해서 여러가지 endpoint 를 열어둔다. 또한 다른 하나의 application 은 spring boot admin server 이다.  필수 dependency 는 actuator 와 admin-client 이다. data-jpa 와 web 그리고 h2 임의의 api endpoint 를 만들기 위해 추가했다. 다음으로 yaml 파일을 보자.  여기서 must 는 admin.client.url 이다. 1. spring.boot.admin.client.url 이다. admin.server url 을 설정하는 것이다. 2. management.endpoints.web.exposure.include 는 내맘으로 "*" 모든 end points 를 열어주었다. clinet application 의 마지막 임의로 만든 api 를...

바로 이전 글  스프링 부트 앱 EB 배포  에서 Spring Boot App 을 AWS console 을 이용해서 Elastic Beanstalk 에 단일 인스턴스 환경으로 배포했다. 하지만, 이전에 올렸던 소스는 local mariaDB 를 바라보고 있다. 따라서 회원가입 및 로그인 기능이 전혀 동작하지 않을 것이다.  이번 글에서 정리할 내용은 local MariaDB 를 AWS RDS MariaDB 를 바라보도록 변경하고, Blue/Green Deploy 를 Jenkins 를 이용해서 진행해볼 예정이다. 아래 포스트들에서 EC2 에 Jenkins 를 설치하고, Gradle 과 Git 을 이용하여 jar 로 Build 하고 S3 versioning 을 통해서 jar 를 관리하는 방법을 정리했었다. EC2에 젠킨스 설치 젠킨스로 Build 하고 S3 로 jar 관리하기 또한 Blue/Green Deploy 를 하기 위해서 기존에 Blue Environment 에 대한 설정을 그대로 따르기 위해, option-settings.json 란 파일을 생성하며 새로운 Environment 생성 시 동일한 구성을 사용할 수 있도록 하겠다. 마지막으로 Jenkins 가 설치된 EC2 에 Elastic Beanstalk Full Access Role 을 부여한다. 기존에 배포된 EB 환경에서는 DB connection 이 이루어지지 않아서 기능이 전혀 동작하고 있지 않은것을 확인할 수 있다. 먼저, local MariaDB 를 바라보고 있는 설정을 AWS RDS MariaDB 로 변경해보겠다. url 을 AWS RDS 로 변경했다. username 과 password 는 보안상의 이유로 적지 않았다. 그럼 이제 변경사항을 push 하고 Jenkins 를 이용하여 Build 하겠다. 젠킨스로 Build 하고 S3 로 jar 관리하기  글에서 작성한 방법으로 Build 를 했다. 다음은 기존 Environment 와 동일한 Environme...