EMD Blog

베이스 이미지로 python:3-slim 사용하고 있음. 해당 베이스 이미지 상에 패키지를 설치할 경우 mysql_config를 찾을 수 없다는 에러가 발생함. 이때 아래 두 패키지를 설치해주면 됨. apt install libmariadb-dev build-essential build-essential는 소프트웨어 컴파일에 필요한 패키지라고 함. https://linuxhint.com/install-build-essential-ubuntu/ 참고 : https://www.sysnet.pe.kr/2/0/12885?pageno=39

빌드 시간 단축하기 캐싱을 활용해 불필요한 빌드과정 제거 캐싱에는 순서가 중요 특정 스텝에서 변화가 발생하면 이후 스텝들은 새로 빌드됨 가장 변하지 않는 스텝을 상위로 자주 변하는 스텝은 하위로 구체적인 COPY COPY . 이런 식으로 하면 어떤 코드가 변경되더라도 새로 빌드됨 캐시할 수 있는 단위 구별 예를 들어 패키지 update와 install을 다른 캐시 단위로 묶으면 예전 버전의 패키지를 다운 받게 될수도 있음 이미지 크기 줄이기 작은 이미지는 배포가 빨라지고 공격 취약점이 작아짐 불필요한 의존성 제거 불필요한 의존성제거 & 디버깅 툴 제거 apt의 경우 no-install-recommends 커맨드로 추천 패키지 설치를 막을 수 있음 패키지 매니저 캐시 제거 패키지를 설치한 RUN 스텝 안에..

이전에 GCP Interconnect 구성 시 발생했던 이슈와 비슷한 이슈. 사무실 network 대역과 docker bridge 대역이 겹쳐서 사무실 네트워크가 연결이 안되는 문제 발생함. 간단하게 docker bridge 대역을 변경해서 해결. 근데 이 이슈는 Linux 계열의 OS에서만 발생하는 이슈로 Docker는 Linux 커널의 container 기술을 사용하기 때문에 MacOS와 Windows에서는 별도의 가상머신에서 Docker를 실행시킨다. 그렇기 때문에 docker bridge 대역이 host machine의 네트워크 인터페이스에 영향을 주지도, 받지도 않는다.

회사 프로젝트 중 크롤링 Batch 서버를 구축해야할 일이 생겼다. 새롭게 들어온 팀원이 맡아서 진행하기로 했는데 기왕 하는 거 Docker Image push 까지 자동화 구축 후 진행을 하면 좀 더 편하게 개발을 하지 않을까 싶어 구축 과정을 간략하게 기록하려한다. 사내 서비스 운영은 인력 부족 및 금액 적인 부분 때문에 AWS에 많이 의존하고 있다. 현재 구축하려는 서비스도 MongoDB를 활용하려다가 데이터가 쌓이면 관리하기 힘들어질 것 같아 DynamoDB를 활용하기로 했다. 구축하고자 하는 개발 프로세스는 다음과 같다. 먼저 로컬에서 github repository를 remote하여 개발하다가 이슈 단위의 작업이 종료되면 Github의 Task branch에 Push 후 develop bran..

배포 자동화와 개발환경 가상화 대부분의 일들은 자동화를 시키면 굉장히 편하고 빠르게 업무를 처리할 수 있다. 개발이라고 다를 것이 없는데 기존의 배포 방식을 먼저 살펴보면 개발환경에서 개발을 하고 목표한 작업이 완료되면 테스트 후 배포한다. 이렇게만 보면 굉장히 간단해 보이고 실제로 어플리케이션 규모가 크지 않으면 간단한 작업이기도 하다. 하지만 어플리케이션 규모가 커지고 배포를 위해 해야할 작업량이 많아진다면 매번 작업단위로 배포하는일은 굉장히 번거로운 일이되버린다. 어차피 배포 자체는 항상 같은 프로세스를 반복하는 것이기 때문에 자동화를 시켜놓는다면 굉장히 편하게 개발을 진행할 수 있다. 그러면 자동화는 알겠는데 왜 가상화를 끼워넣었을까 아래의 예시를 보자 기존에 운영중이던 사내 서비스 중 PHP로 ..