피츠버그와 클리블랜드의 Docker 컨설팅 및 지원

애플리케이션 컨테이너화

애플리케이션을 컨테이너화하기 전에 무엇을 읽고, 무엇을 쓰고, 어떤 포트를 사용하며, 시작할 때 무엇이 필요한지 파악합니다. 코드와 런타임은 폐기 가능합니다. 데이터베이스와 업로드된 파일은 유지되어야 하므로 컨테이너 안이 아니라 이름이 있는 볼륨이나 바인드 마운트에 둡니다.

데이터베이스 비밀번호 같은 시크릿은 이미지와 버전 관리에 넣지 않습니다. 컨테이너가 시작될 때 전달합니다.

기업 애플리케이션을 위한 Docker Compose

호스트 한 대에는 Docker Compose가 적합한 도구인 경우가 많습니다. 파일 하나에 애플리케이션, 데이터베이스, 캐시를 정의하고 명령 하나로 전체를 시작합니다.

• 리버스 프록시 및 TLS: 프록시가 HTTPS를 종단하고, 호스트 이름별로 라우팅하며, 인증서를 갱신하므로 애플리케이션이 직접 노출되지 않습니다.
• 재시작 동작: 재시작 정책과 상태 점검이 충돌이나 재부팅 후 서비스를 복구합니다.
• 모니터링: 가동 상태 점검과 로그가 다른 시스템과 같은 대시보드에 표시됩니다.

이미지 레지스트리 및 CI 빌드

노트북에서 이미지를 빌드해 서버에 복사하는 방식은 한 사람을 넘어서면 확장되지 않습니다. 프라이빗 레지스트리와, 코드가 바뀔 때마다 이미지를 빌드하고 버전 태그를 붙여 게시하는 GitLab CI 파이프라인을 구성합니다. 배포는 태그가 지정된 검증된 이미지를 가져오며, 롤백은 이전 태그를 가리키는 것으로 끝납니다.

백업 및 보안 업데이트

컨테이너는 폐기 가능하지만 볼륨은 그렇지 않습니다. 볼륨과 데이터베이스를 일정에 따라 백업하고, 사본을 오프사이트로 보내며, 복원을 테스트합니다. 데이터베이스 컨테이너에는 실행 중인 서비스의 파일을 복사하지 않고 데이터베이스 자체의 덤프 또는 백업 방식을 사용합니다. 백업 및 재해 복구 서비스를 참고하십시오.

보안 업데이트는 두 계층으로 이루어집니다. 호스트 운영체제를 패치해야 하고, 기본 이미지나 라이브러리가 수정되면 이미지를 다시 빌드해야 합니다. 둘 다 일정을 잡아 실행하고 결과를 테스트하며 이전 버전을 계속 사용할 수 있게 둡니다. Docker 호스트는 흔히 Proxmox 위의 가상 머신으로 실행됩니다.

Kubernetes로 옮겨야 할 때

Docker Compose는 호스트 한 대에서 실행됩니다. 그 호스트를 잃는 것이 더 이상 허용되지 않거나, 서비스를 여러 머신에 분산하고 중단 없이 업데이트하며 머신이 고장 나면 다른 곳에서 재시작해야 할 때 Kubernetes를 고려하십시오. 클러스터는 운영에 더 많은 노력이 들기 때문에, 이러한 요구가 있을 때만 권장합니다. 그 시점에는 Linux 및 Kubernetes 컨설팅에서 설명하는 클러스터로 워크로드를 옮깁니다.

진행 방식

1. 상담 통화. 애플리케이션이 하는 일과 실행되는 위치를 파악합니다.
2. 서면 범위 정의. 컨테이너, 프록시, 백업, 업데이트에 대한 계획입니다.
3. 구축 및 인계. 배포하고, 복원을 테스트하며, 운영 방법을 문서화합니다.
4. 지속적인 지원. 선택 사항이며, 담당 엔지니어가 배정됩니다.

영업일 기준 1일 이내에 답변드립니다. 사무소는 펜실베이니아의 Coraopolis와 Beaver Falls에 있으며, 클리블랜드 지역 현장 작업은 프로젝트 일정에 맞춰 진행합니다.

Docker 지원에 대한 질문

Docker Compose를 운영 환경에 써도 충분합니까?

호스트 한 대에서 실행되는 많은 업무용 애플리케이션에는 충분합니다. 단, 백업, 모니터링, 패치 절차가 있어야 합니다. 호스트 간 장애 조치는 제공하지 않습니다.

직접 만들지 않은 소프트웨어도 컨테이너화할 수 있습니까?

대개 가능합니다. 많은 애플리케이션이 컨테이너 이미지를 제공하며, 이를 구성하고 백업합니다. 맞춤 개발 소프트웨어는 직접 패키징하거나 귀사의 개발자와 협력합니다.

다른 업체가 설정한 Docker 서버도 인수할 수 있습니까?

네. 컨테이너, 볼륨, 인증서를 목록으로 정리하고 백업을 점검하며, 무엇이든 변경하기 전에 파악한 내용을 문서화합니다.