Monolithic 서버사이드 타입스크립트 세팅 03

이놈의 Hexo 블로그가 future라는 옵션을 켜면 미래 글까지 보여준다는 걸 처음 알았다. 원래 2편이 12일에 올라가길 바랐던 글인데, 3시간 후라는 이름으로 11일에 올라갔다, 귀찮기 때문에 내리진 않았다.

이 주제로 마지막 글이다. 이번 글에서는 도커라이징을 해서 로컬 개발 환경을 구성하고, 개발 서버, 운영 서버로 나눠서 배포할 수 있는 환경 구성을 해보려고 한다. 도커라이징과 관련된 내용은 과거에 개발 환경과 관련된 글을 썼는데, 그 글에서 조금 더 자세하게 확인할 수 있긴 하다. 지금까지 진행된 내용은 아래와 같다.

도커 베스트 프랙티스 (번역)

깃헙에는 현재 백만이 넘는 도커파일들이 있다. 하지만 모든 도커파일들이 동일하지는 않다. 효율성은 중요한 것이고, 이번 블로그 시리즈는 도커파일의 다섯 가지 영역: 빌드 시간의 증가, 이미지의 사이즈, 유지성, 보안, 반복성에 있어서 베스트 프랙티스를 다룰 것이다. 만약 독자가 도커에 막 시작하는 사람이라면, 이 글은 독자를 위한 글이다! 이후 시리즈는 좀 더 Advanced한 주제가 될 것이다.

복잡한 애플리케이션 설정을 위한 복수의 도커 파일 사용하기(번역)

대부분의 웹 기반의 앱은 실제 서비스에서 개발자가 높은 트래픽에서 증가하는 워크로드를 처리할 능력을 더할 수 있게 하는 여러 컨테이너들을 사용하게 된다. 여러 도커파일을 사용하는 것은 개발자에게 어떻게 하나의 애플리케이션을 분할할 것인지를 결정하는 것을 돕고, 그러므로서 기능적인(함수적인) 집계가 동작할 수 있게 하지만, 개발자는 결정을 내리는 과정 중에 반드시 먼저 스스로에게 몇가지 질문들을 해야 한다.

개발자는 아마도 복수의 도커파일을 로드밸런서 앞단에서 동작하는 프론트앤드에서 작동하는 노드를 유저의 요청에 맞추기 위해 사용할 것이다. 하지만 개발자는 어떤 앱이 도커파일을 통해 이득을 얻을 수 있을지, 얼마나 많은 도커파일들이 각 애플리케이션에 필요한지, 그리고 개발자가 도커파일을 추적하는 과정을 취할 수 있는지와 같은 반드시 몇 요인들을 결정해야 한다.

컨테이너 서버리스 Fargate 배포하기

최근 개발 중인 앱이, 이제 서비스 준비를 앞 두고 있는데, 개발자가 부족하므로, 운영 환경에 최대한 얽메이지 않고 싶다는 욕구에 의해 컨테이너 서버리스인 Fargate 배포에 눈을 돌리게 되었다. 이 글에서는 AWS ECS를 동작하기 위한 가장 기본적인 개념과 Fargate가 무엇인지 간단하게 설명한 다음 사이드 프로젝트로 진행 중이던 프로젝트를 Fargate 위에 띄우는 것까지 해볼 계획이다.

Docker로 개발 환경 구축하기 (2)

그 전 글은 여기에서 볼 수 있다.

이제 우리는 Docker 이미지를 다룰 수 있다. 이미지를 다루는 방법을 잘 모르는 상태라면 이전 글을 읽고 오는 편이 좋지만, 알고 있다면 더 준비할 내용 없이 바로 이 글을 읽어도 좋을 것 같다. 컨테이너를 다루는 방법은 이미지를 다루는 방법에 비해서 짧고 간단하다.

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×