도커 볼륨 이전 포스트에서 도커 이미지는, 컨테이너를 띄운 이후 읽기 전용으로 바뀌어 컨테이너에서 일어난 어떤 변경사항도 도커 이미지에 적용되지 않는다고 했다. 물론 commit을 하게 되면 변경사항이 적용된 새 이미지가 생기지만 기존의 이미지는 영향을 받지 않는다. 바꿔 말해 컨테이너는 베이스 이미지에 종속적이고 삭제가 된다면 자신의 상태를 잃어버리게 된다는 것이다. 도커 컨테이너는 생성과 삭제가 빈번하다 보니 이럴때마다 데이터를 잃어버리면 치명적이다. 도커 볼륨은 이를 해결하기 위해 등장한 도커 오브젝트이다. 리눅스 마운트 네임스페이스를 이용한 컨테이너 내의 파일 시스템을 관리한다. 도커 볼륨을 통해 데이터를 Persistent하게 유지하는 총 3가지 방법에 대해 알아보자. 호스트 볼륨 공유 이름에서..

도커 이미지 도커 이미지는 컨테이너를 생성할 때 필요한 요소이다.(VM에서 쓰는 iso 파일과 비슷) 쉽게 얘기하면 이미지는 컨테이너를 찍어내는 틀이고, 컨테이너는 틀로부터 생성된 애플리케이션이다! 도커 이미지 이름 imsongkk/ubuntu:14.04 imsongkk : 저장소 이름, Docker Hub나 AWS ECR 같이 docker image를 저장할 수 있는 repository의 이름이다. local에서만 이미지를 빌드할것이라면 저장소 이름은 필수가 아닐 수 있다. ubuntu : 이미지 이름, 해당 이미지의 이름으로 어떤 애플리케이션인지를 나타낸다. 14.04 : 태그, 1편에서 다뤘듯이 도커의 장점은 버전 관리가 된다는 것이다. 애플리케이션의 버전 정보를 나타내는 리비전으로 태그를 사용할 ..

Docker 한줄 요약 도커는 리눅스 컨테이너에 여러 기능을 추가함으로써 애플리케이션을 컨테이너 단위로 사용할 수 있게 Golang으로 만들어진 오픈소스 프로젝트이다. 리눅스 컨테이너? 리눅스 컨테이너는 리눅스 운영체제 수준의 가상화 기술로, 컨테이너화 된 애플리케이션은 운영체제 커널과 격리된 공간에서 실행된다. 이것을 가능케 해주는 것은 리눅스에 있는 namespace와 cgroup(컨트롤 그룹)이다. 리눅스 네임스페이스 리눅스에서 프로세스를 관리하는 방법으로는, 커널이 PID 1을 가지는 init 프로세스를 실행시키고 해당 프로세스의 자식으로 프로세스를 생성한다. 이때 자식들은 별도의 네임스페이스를 지정해주지 않으면, init 프로세스의 네임스페이스 속하게 되고 이는 리눅스 시스템 기본 네임스페이스가..

Docker 도커를 처음 접한건 학회였다. 학회에서 데이터 엔지니어링팀에 속해 정규 세션을 들었었는데, 그때 Docker에 대해 알게되었다. 사실 도커라는 키워드는 그 이전부터 몇번 들었었다. 주변에서 그거 그냥 도커로 배포해~~, 학교 os 과제 도커로 가능? 이런 말들을 가끔 들을때 마다 도대체 도커가 뭐길래? 라고 생각이 들었다. 아무튼 학회에서 세션을 듣고 나서 흥미가 생겨 따로 학회원들과 책을 정해 스터디를 진행했었다. 아무래도 실습 없이 책으로만 공부하다보니까 뭔지는 알겠는데 그래서 이걸 어디에 써야할지 몰랐었다. 그렇게 기억 저편으로 잊혀졌다가 인턴을 하며 실제 내가 배포까지 맡아서 해야하는 상황에 닥치자 도커는 나에게 한줄기 빛이 되었다.... 도커 없이는 못사는 몸이 되어버린 이 시점에서..

일반적인 아키텍쳐 4가지의 계층으로 나누어져 어플리케이션을 구성한다. 표현 계층(UI)는 응용 계층을 위해 정보를 가공한다. 응용 계층은 도메인 계층을 가지고와 메소드를 호출한다. 응용 계층은 데이터의 저장을 위해 인프라스트럭쳐에 의존한다. 일반적으로 상위 계층이 하위 계층에 의존하는 구조를 가지고 있다. 이전 포스트에서 도메인 영역에서 도메인 핵심 규칙을 구현한다고 하였는데, 구현한 기능을 누가 사용하고 누가 관리할까? 바로 응용 계층이다. 스프링을 한참 공부하면서 Controller, Service, Repository 컴포넌트들의 역할을 무엇이고 왜 나누어져있는지 궁금했다. 맨땅에 박치기 방식으로 개발을 하다보니 Controller는 Service에서 사용할 데이터 가공, Repository는 Se..

도메인이란? 다시, 도메인의 정의는 무엇일까? 도메인은 개발자가 구현으로 해결하고자 하는 문제 영역이다. 개발을 하기 앞서, 기획과 기능을 정한다. 이는 개발자가 직접 정할수도있고, 또는 기획자나 stakeholder에 의해 정해질 수 있다. 도메인은 이들이 공통적으로 집중할 수 있는 소통창구 역할을 한다. 도메인 모델 패턴 일반적인 어플리케이션의 아키텍쳐는 다음과 같다. 표현(UI) 사용자의 요청 처리 응용(Service) 사용자가 요청한 기능 실행, 비즈니스 로직을 직접 구현하지 않고 도메인 계층을 조합하여 기능을 실행 도메인 도메인 규칙 구현 인프라스트럭쳐 DB나 MQ같은 외부 시스템과의 연동을 처리 도메인 계층은 도메인의 핵심 규칙을 구현한다. 도메인의 핵심 규칙은, '출고 전에 배송지를 변경할 ..

DDD란 무엇일까? Domain Driven Design, 도메인 주도 개발이라는 뜻이다. 일반적인 백엔드 서버 개발은 DB와 뗄 수 없는 구조이다. 오히려 서버 로직 구성보다, DB 테이블 설계와 객체 생성에 더 시간을 많이 쏟는다. DDD는 도메인 모델이라는 키워드에 집중해, 어플리케이션 구성을 더 효율적으로 하는 일종의 방법론이다. 까지가 내가 아는 전부이다.... 주변 백엔드 개발자로부터 DDD를 공부해보라는 추천을 받아서 이번 기회에 공부하려고 한다. 학교 도서관에서 우연히 다음과 같은 책을 발견해서 얘로 결정!

하나의 인스턴스에서 A, B 두개의 git remote repo에 각각 접근하는 상황 cd ~/.ssh pwd // 별다른 설정을 하지 않았다면 /home/ec2-user/.ssh mkdir A mkdir B ssh-keygen -f ~/.ssh/A/id_rsa //A 폴더에 pub키 생성 ssh-keygen -f ~/.ssh/B/id_rsa //B 폴더에 pub키 생성 vim config // ~/.ssh/config Host A Hostname github.com PreferredAuthentications publickey IdentityFile ~/.ssh/A/id_rsa Host B HostName github.com PreferredAuthentications publickey Identity..

git filter-branch -f --index-filter 'git rm --cached --ignore-unmatch src/main/resources/application-jwt.yml' --prune-empty -- --all src/main/resources/application-jwt.yml 파일을 history삭제한다.(로컬에 존재하는 파일은 삭제되지 않음) 이후 git push -f origin --all 해서 remote에도 반영되도록 하자 키값을 실수로 remote에 잘못올려서 고생 ㅠ

리액트 앱을 빌드하게 되면 기본 포트로 3000이 할당된다. my-hompage.com:3000 으로 접속해야 내가 빌드한 리액트 앱의 화면이 나오게 된다. Spring은 기본 포트가 8080으로 할당이 되므로 Rest API를 호출할때면 my-server.com:8080/api 이런식으로 호출해야 한다. 이때 포트번호를 생략하게 되면 당연히 해당 프로세스를 찾지 못해 Http 통신이 불가능하다. my-hompage.com 혹은 my-server.com/api 이런 형태로 Http 통신을 하고 싶다면 어떻게 해야 할까? 기본적으로 Http 통신은 80 포트를 통해서 하게 된다. 그러므로 주소창에 naver.com을 입력해 얻는 결과는 사실 naver.com:80을 입력해 얻는 결과이다. 따라서 우리는 다..