TIL(1월) - 3

4 분 소요

틀린 내용이나 본문의 내용과 다른 의견이 있으시면 댓글로 남겨주세요!

TIL의 포스팅 길이가 과도하게 길어져 나누어서 포스팅 합니다.

01/31

DNS (Domain Name Server)

DNS - godaddy

01/29

Java의 Collections framework

Collection 하위에는 Set, List, Queue가 있다. 그리고 Map은 따로 있다.

Collection과 Map의 차이는 Value로만 이루어져있냐, Key-Value 쌍이냐 이다.

Collection 하위에 Set이 중복을 허용하지 않는다 라고 할 수 있는데, 이는 구현체에 따라 다르다. 만약 Set을 구현하는 구현체를 중복을 허용하는 집합(순서가 상관없는 값들의 모음)으로 구현한다면, 중복이 허용되는 Set이 만들어질 수 있는 것이다.

자바에서 HashSet 은 내부적으로 HashMap을 사용하여 구현되어있다. 대신 HashMap의 Key-value 쌍의 형태로 데이터를 갖는 것이 아닌, Value만 갖는다. 그래서 HashSet은 HashMap의 Key-value 중 Key의 위치에 있는 값을 Element로 갖는다.

public class HashSet<E>
    extends AbstractSet<E>
    implements Set<E>, Cloneable, java.io.Serializable
{
    static final long serialVersionUID = -5024744406713321676L;

    private transient HashMap<E,Object> map;

    // Dummy value to associate with an Object in the backing Map
    private static final Object PRESENT = new Object();

    /**
     * Constructs a new, empty set; the backing <tt>HashMap</tt> instance has
     * default initial capacity (16) and load factor (0.75).
     */
    public HashSet() {
        map = new HashMap<>();
    }

    ...

위와 같은 방식으로 구현 되어있다.

01/25

Pipeline Syntax (Scripted pipeline)

Scripted pipeline

01/24

Jenkinsfile

01/23

Dockerhub Webhook

Docker Hub의 push event에 대한 응답으로 다른 서비스에 액션을 할 수 있는 webhook을 사용할 수 있다. Webhook은 docker hub에서 네가 정의한 URL로 POST 요청이다.

Docker hub repository의 Webhook 탭에서 설정할 수 있다.

dockerhub_webhook

레파지토리의 webhook 탭에서 웹훅을 만들수 있다. 웹훅 이름과 웹훅 URL의 도착지를 설정한다.

Webhook delivery history도 확인할 수 있다.

Webhook payload

Docker Hub의 Webhook payload는 다음 JSON 형식의 페이로드를 갖는다.

{
  "callback_url": "https://registry.hub.docker.com/u/svendowideit/testhook/hook/2141b5bi5i5b02bec211i4eeih0242eg11000a/",
  "push_data": {
    "images": [
        "27d47432a69bca5f2700e4dff7de0388ed65f9d3fb1ec645e2bc24c223dc1cc3",
        "51a9c7c1f8bb2fa19bcd09789a34e63f35abb80044bc10196e304f6634cc582c",
        "..."
    ],
    "pushed_at": 1.417566161e+09,
    "pusher": "trustedbuilder",
    "tag": "latest"
  },
  "repository": {
    "comment_count": 0,
    "date_created": 1.417494799e+09,
    "description": "",
    "dockerfile": "#\n# BUILD\u0009\u0009docker build -t svendowideit/apt-cacher .\n# RUN\u0009\u0009docker run -d -p 3142:3142 -name apt-cacher-run apt-cacher\n#\n# and then you can run containers with:\n# \u0009\u0009docker run -t -i -rm -e http_proxy http://192.168.1.2:3142/ debian bash\n#\nFROM\u0009\u0009ubuntu\n\n\nVOLUME\u0009\u0009[/var/cache/apt-cacher-ng]\nRUN\u0009\u0009apt-get update ; apt-get install -yq apt-cacher-ng\n\nEXPOSE \u0009\u00093142\nCMD\u0009\u0009chmod 777 /var/cache/apt-cacher-ng ; /etc/init.d/apt-cacher-ng start ; tail -f /var/log/apt-cacher-ng/*\n",
    "full_description": "Docker Hub based automated build from a GitHub repo",
    "is_official": false,
    "is_private": true,
    "is_trusted": true,
    "name": "testhook",
    "namespace": "svendowideit",
    "owner": "svendowideit",
    "repo_name": "svendowideit/testhook",
    "repo_url": "https://registry.hub.docker.com/u/svendowideit/testhook/",
    "star_count": 0,
    "status": "Active"
  }
}

Callback을 검증하기 위해서는, JSON payload에 callback_url을 찾고, 이 URL에 유효한 JSON body를 포함한 POST 요청을 보낸다.

CALLBACK JSON DATA

state(required): 성공, 실패, 에러를 담음 - success가 아니면 웹훅 체인은 중단된다.
description: Docker hub에서 사용할 수 있는 기타 정보를 포함할 수 있는 String, 최대 255자
context: Operation 컨텍스트를 포함하는 String, Dockerhub에서 검색할 수 있다. 최대 100자
target_url: 작업 결과를 찾을 수 있는 url, Dockerhub에서 검색할 수 있다.

예시는 다음과 같다.

{
  "state": "success",
  "description": "387 tests PASSED",
  "context": "Continuous integration by Acme CI",
  "target_url": "http://ci.acme.com/results/afd339c1c3d27"
}

참고자료(Docker Hub webhook)

Docker 공식문서

01/22

RDS vs. EC2

Amazon RDS는 관계형 DB를 쉽게 설정, 운영, 확장 할 수 있는 웹 서비스다. Aurora, PostgreSQL, MySQL, MariaDB, Oracle Database, MSSQL 중 하나의 데이터베이스 엔진 중 선택할 수 있다. 사용자가 애플리케이션에 집중할 수 있도록 해준다.

Amazon EC2(Elastic Compute Cloud)는 크기, 용량 조절 가능한 컴퓨팅 파워를 클라우드에서 제공하는 웹 서비스다. 이 내부에서 데이터베이스를 관리할 수 있다. 데이터베이스 인스턴스 및 스토리지를 프로비저닝하고 구성할 수 있다.

RDS는 AWS가 데이터베이스를 전적으로 책임진다. 모든 데이터베이스의 설정, 관리, 유지보수, 보안 등은 모두 AWS가 자동화한다. 설정을 간단하게 바꾸면서 데이터베이스의 컴퓨팅, 스토리지 리소스를 확장 할 수 있다.

RDS는 Database의 설정에 신경 쓸 필요가 없게 한다. 대신 EC2는 데이터베이스, OS, Software stack을 완전하게 제어할 수 있게 한다.

그래서 개발초기에 RDS를 이용하여 데이터베이스에 대한 설정을 신경쓰지 않고 애플리케이션에 집중하여 개발하고, 점점 데이터베이스에 대한 통제를 완벽하게 제어할 필요가 생긴다면 EC2를 사용하는 것이 좋을 것 같다.

EC2와 RDS 각각 성능과 요금적인 측면에서 고려해보고 적절한 서비스를 사용하는 것이 좋을 것 같다.

참고자료(RDS vs. EC2)

01/21

CI/CD

CI - 코드 버전관리 시스템(Git 같은..)에 푸시가 들어오면 자동으로 테스트와 빌드가 수행되어 배포 파일을 만드는 과정

CD - 이 빌드 과정을 거쳐 나온 결과를 자동으로 운영 서버에 배포하는 과정

지속적 통합을 위해서는 테스트의 자동화가 무엇보다 중요하다. 이 프로젝트가 완전한 상태임을 보장하기 위해 테스트 코드가 구현되어 있고, 이게 통합 프로세스마다 돌아야한다.

빌드와 배포를 한꺼번에 할 수도 있지만, 분리해놓는다면 배포만 필요한 순간(기존에 만들어진 jar파일을 배포만 하면 되는 경우)에도 배포만 따로 수행할 수 있을 것이다.

이동욱님 책에서는 CI 도구를 통해 나온 jar파일을 S3로 올리고, 이 jar파일을 배포할 때 AWS Code Deploy를 사용한다고 한다. AWS Code Deploy는 대체제가 없다고 하셨는데, 이유가 CI 서버와 배포 서버를 따로 두어야 하기 때문이라고 생각한다. Jenkins가 설치된 서버를 운영서버로 바로 활용한다면, 젠킨스 파이프라인 돌면서 어플리케이션의 배포까지 수행하면 되지만, 지속적 통합 서버와 배포(운영) 서버를 따로 두어야하기 때문에 Code Deploy 외에는 방법이 없는 것 같다.

CI 파이프라인을 돌고, 이를 통해 나온 jar파일을 운영서버로 따로 쏴주는 전송 시스템이 필요할 것인데, 이동욱님 책에서는 이를 S3와 Code Deploy를 활용하여 배포하신 것 같다.(아직 정확하게 읽지는 않았다.)

그러면 이 결과 jar파일을 다른 EC2로 보내주고, 이 EC2에서 새로운 버전의 jar파일을 인식하고 자동적으로 실행하는 로직이 수행되면 될 것 같다. DockerHub에 새로운 이미지 푸시에 webhook을 가지고 이것을 트리거로 새로운 이미지로 컨테이너를 새로 띄우는 방식으로 자동화를 시도 해볼 예정이다.

참고할 자료: Docker Hub webhook

PSA (Portable Service Abstraction)

이식 가능한 서비스 추상화..? 그러니까 잘 만든 인터페이스. 테스트 하기도 좋고, 바꿔끼우기에도 좋다. 적용하려는 기술에 상관 없이 일관성 있게 코드를 작성할 수 있게 해준다.

JPA를 쓰다가.. Hibernate를 쓰다가.. 바꾸더라도 나의 코드를 바뀌지 않는다.

그러니까 우리가 @Controller, @GetMapping, @PostMapping과 같은 어노테이션으로 웹 어플리케이션을 구현하고 있고, 이는 서블릿 컨테이너를 기반으로한 어플리케이션 형태이다. 이러한 코드 베이스를 변경하지 않더라도 Reactive 방식으로 기술을 변경하여 새로운 방식으로 변경할 수 있게 되는 것이라고 생각한다.

특정 기술에 종속되지 않고, 확장성이 있도록 만들게 한 것이 Spring의 근본 원칙이다.