DevOps

매일 시간 날 때마다 geeknews를 보는 편이다. 이런저런 글들 중에서 가장 관심 있는 글을 발견하였는데 그것은 바로 도커의 멀티 스테이지 빌드에 대해서 쓰인 글이었다.[geeknews] Docker multi-stage build로 컨테이너 이미지 크기 줄이기 : https://news.hada.io/topic?id=17794 Docker Multi-Stage Build로 컨테이너 이미지 크기 줄이기 | GeekNewsDocker 컨테이너 이미지를 빌드할 때, Dockerfile이 Multi-Stage 구조가 아니라면 불필요한 파일이 포함될 가능성이 큼이는 이미지 크기 증가 및 보안 취약성 증가로 이어짐컨테이너 이미지에서 발생할news.hada.io 해당 게시글을 보고 바로 링크된 원문을 확인하여 ..

클라우드 기반이 아무래도 편하다 보니까 AWS를 통해서 다양한 서비스들을 직접 띄우면서 작업하는 도중이었으나, 최근에 일과 개인적인 공모전 관련해서 AWS를 쓰기 힘든 상황이다 보니까 온프레미즈를 통해서 배포하기 시작했다. 아무래도 AWS를 쓰는 편이 편하기는 하지만, 비용적인 측면을 고려할 수밖에 없었고, 학교에서 일하게 되면서 서버 리소스들이 꽤나 많기 때문에 대부분 Jenkins를 기반으로 서빙하기 시작했다. 빌드의 꽃은 역시 매개 변수를 넣어주는 것이라고 생각한다. 도커 이미지를 만드는 과정에서도 다른 사람들의 스크립트를 보면서 저마다 도커 이미지를 빌드하는 방법이 다 다르다고 생각하였는데, 각각 다양한 이후의 확장성을 고려한 도커 파일을 작성하는 것이었다. 그렇기 때문에 이러한 젠킨스 빌드에서도..

먼저, 이전에 개인 프로젝트를 통한 AWS Serverless 배포 파이프라인을 구축하였다. 많은 요소들을 신경 써서 여러모로 구축하였고, 서버 비용도 예상할 수 있는 수준 이내로 끊으려고 했었다. 그런데 한 가지 문제가 발생하는데... 그것은 바로 배포가 무려 30분이나 걸린다는 사실이었다. 그 이유는 다음과 같았다. cpu 2 core, memory 4GB씩 물려 있던 ECS의 리소스를 비용 문제로 각각 절반식 줄여버린 것이다. 사실 생각해 보면 이미 예견된 문제였었다. AWS freetier에서 지원하는 ec2 t2.micro에서 스프링을 빌드해 본 적이 있다면 알 수 있을 것이다. 1 core와 1GB memory를 지원하는 t2.micro에서 gradlew build를 실행하면, 빌드 도중에 메..

들어가며평소에도 그렇고 일을 하면서도 그렇고, 프로젝트에서도 배포쪽으로 다양하게 서포트하는 쪽이라 nginx를 굉장히 많이 사용하는 편이다. 특히 학교에서 일하게 되면서 네트워크 정책이 전산을 관리하는 곳에서 통제하기 때문에 제한된 구조로 특정 포트밖에 이용할 수 없게 된다. 이 때 nginx를 극한으로 사용하는 방법에 대해서 알아보기 시작하였다. nginx를 리버스 프록시 및 로드 밸런싱과 같이 다양한 방법으로 사용하다가 Nginx Proxy Manager라는 것을 알게 되었다. 굉장히 신세계였는데, 매번 nginx.conf를 직접 설정하고 nginx -t로 문법 체크하고, reload하는 것과는 다르게, 손쉽게 SSL을 통한 https 접속 및 서브 도메인 로드 밸런싱을 지원하는 점이 좋았다. 더 말..

최근 AWS 기반으로 CI/CD 파이프라인이 구축되어 있던 것을 온프레미즈로 옮기고 있기도 하고, 현재 일하는 곳에서 젠킨스를 이용한 CI/CD 파이프라인을 구축해야할 일이 있었다.젠킨스에 대해서 자세하게 다뤄본 적은 없었으나, 컨테이너를 통하여 젠킨스를 띄우고 젠킨스에서 다른 컨테이너를 컨트롤 하는 상황일 때, 꽤나 잔 에러가 많이 난다고 듣기만 하고서 선뜻 다뤄보지 못했다. 이번 포스팅에서는 docker를 통해 젠킨스를 띄우는 방법에 대해서 다룰 예정이며, dood 방식으로 진행한다. 파이프라인 구성에 대한 자세한 부분은 담지 않는다. 본론DinD? DooD? DinD ( Docker in Docker )먼저 DinD는 말 그대로 Docker를 컨테이너 안에 설치하여 실행하는 방법이다. 즉, 하나의 ..

앞서 포스팅에서 프론트엔드 배포에 대한 설정은 끝났다. 이제 백엔드 배포와 함께 해당 프로젝트의 전반적인 CI/CD 구성을 끝낼 예정이다. 전반적인 아키텍처는 아래와 같이 구성될 예정이다. 이번에도 Github actions를 통해 IAM으로 접근하는 방법이다. 백엔드 개발자가 github actions 설정을 통해서 코드를 푸시하는 순간 바로 ECS를 통해 배포되도록 구성했다. 백엔드 배포는 프론트엔드와 같이 완전한 Serverless를 이루도록 설정해 두었다. 즉, 스케일 아웃이 설정에 따라 알아서 진행되는 아키텍처로 설계하였다. 먼저 프로젝트를 진행하기 전에 앞서 알아두어야할 것들이 몇 가지 있다. 첫 번째로는 서버리스 아키텍처를 위해 ECS의 Fargate를 사용하는데, 이 경우에는 메모리와 CP..

최근 피우다 프로젝트라는 공모전에 다섯 명으로 팀을 꾸려 참가하였다. 개발 경력이 가장 길었기에 PM이자 팀장 포지션으로 다른 개발자들을 서포트하는 포지션으로 프로젝트에 임하게 되었다. AWS를 통해 프론트엔드와 백엔드를 배포하는 CI/CD를 전체적으로 구성하였는데, 전체적인 아키텍처는 위와 같았다. freetier를 사용하는 수준에서 처리할 수 있었고, 수많은 AWS의 서비스를 사용함으로써 AWS 아키텍처의 기본기를 제대로 다뤄보았다고 생각했다.  이번 포스팅은 프론트엔드편과 백엔드편으로 나뉘어 배포하는 과정을 나타낸다. 해당 과정에 대해서 다시 한번 블로그에 복기함으로써 어떤 식으로 아키텍처를 구성했는지 리마인드함과 동시에 다른 개발자들도 참고할 수 있게 글을 작성한다. 이번 포스팅에서 다룰 전반적인..

저번 포스팅에서는 node-exporter를 통해서 리눅스 시스템을 모니터링하는 방법을 알아봤다. 이번에는 심층적으로 redis를 모니터링해 보자.본론먼저 소스 코드의 예제는 아래와 같다. 궁금하면 직접 docker-compose를 통해서 빠르게 실행해 볼 수 있다.Github Example : https://github.com/marsboy02/redis-exporter-monitoring GitHub - marsboy02/redis-exporter-monitoring: redis-exporter를 사용해서 모니터링하는 소스 코드의 예제입니다redis-exporter를 사용해서 모니터링하는 소스 코드의 예제입니다. Contribute to marsboy02/redis-exporter-monitoring..