Java 개발자를 위한 DevOps 도구

8장. 개발자용 배포

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

아나 마리아 미할시아누

전략이 아무리 훌륭해도 가끔은 결과를 살펴봐야 합니다.

윈스턴 처칠 경

컴퓨터가 매우 크고 비쌌을 때 제조업체는 종종 소프트웨어와 하드웨어를 함께 번들로 제공했습니다. 대중적인 소프트웨어가 개발되면서 이러한 작업은 시간이 많이 걸렸고 새로운 형태의 소프트웨어 배포가 등장했습니다. 오늘날의 개발 프로세스는 빌드와 배포 활동을 분리하여 빠른 소프트웨어 배포와 팀 내 병행 활동을 촉진하는 데 중점을 둡니다.

애플리케이션 배포는 해당 소프트웨어가 패키지화된 아티팩트에서 운영 가능한 작동 상태로 전환되는 것을 의미합니다. 오늘날의 개발 환경에서는 시스템의 실행 상태에 대한 신속한 피드백을 얻기 위해 이러한 전환이 최대한 빨리 이루어져야 합니다.

개발자는 주로 성능 좋은 애플리케이션 코드를 작성하는 데 집중합니다. 하지만 DevOps는 협업 중심이며, 여러분의 작업은 인프라 내에서 완벽하게 조화를 이루어야 합니다. 배포 프로세스를 살펴보면서 "내가 구상한 대로 이 배포를 실행하려면 기계에 어떤 명령이 필요할까?"라고 끊임없이 질문하고 인프라 및 자동화를 담당하는 동료 또는 전문가와 공유해야 합니다. 배포 프로세스를 계획할 때 나중에 분산 시스템의 더 많은 구성 요소로 확장할 수 있는 위시리스트를 작성할 수 있습니다:

• 시스템의 기능을 점진적으로 확장하려면 소규모 배포를 자주 수행하세요. 이 접근 방식을 사용하면 장애가 발생할 경우 이전 작동 상태로 쉽게 롤백할 수 있습니다.

• 각 마이크로서비스를 개별적으로 확장하거나 교체할 수 있어야 하므로 각 마이크로서비스의 배포를 분리하세요.

• 이미 배포된 마이크로서비스를 다른 환경에서 재사용할 수 있어야 합니다.

• 인프라 배포를 자동화하고 애플리케이션 기능으로 인프라를 발전시키세요.

마이크로서비스를 배포할 컨테이너 오케스트레이션 플랫폼에 관계없이 애플리케이션을 패키징하는 것으로 시작하여 다음을 계속 진행하게 될 것입니다:

1. 컨테이너 이미지 빌드 및 푸시

2. 배포 전략 선택 및 구현

애플리케이션 배포가 다양한 단계 또는 환경에서 진행됨에 따라 다음과 같은 일이 발생할 수 있습니다:

워크로드 관리

느리거나 응답하지 않는 기능을 방지하기 위해 상태 확인과 CPU 및 메모리 사용량을 세분화하세요.

관찰 가능성 측면

메트릭, 로그 및 추적을 사용하여 분산 시스템 내부에 대한 가시성을 제공하고 그 결과를 측정하세요.

이 장에서는 이러한 활동을 살펴보고 그 규모에 따른 영향을 살펴봅니다.

컨테이너 이미지 빌드 및 푸시

애플리케이션을 컨테이너에 배포하려면 Java 애플리케이션 아티팩트를 생성하고 컨테이너 이미지를 빌드해야 합니다. 6장에서 공유한 권장 아티팩트 형식과 사례를 활용하면 컨테이너 이미지 생성에 집중할 수 있습니다.

2013년에 Docker가 등장하면서 Docker파일을 사용하여 컨테이너 이미지를 빌드하는 ...