개발자가 Docker에 관심을 가져야하는 이유는 무엇입니까?

11

일반적으로 개발자는 비즈니스 요구 사항 충족에 관심을 갖습니다. 특정 스택 또는 프레임 워크에 대한 전문 지식이있을 수 있습니다. 그러나 도커를 배우려고 노력해야하며 다양한 배포 방법 (swarm, kube, mesos 등)입니까?

단순히 개발자가 도커에 관심을 가져야하는 이유는 무엇입니까?

추신 :이 게시물의 부모 질문 은 개발 팀에 도커를 도입 한 의미입니다.

docker project-management orchestration

— 압하이 파이
소스

7

아마 당신이 찾고있는 대답은 아니지만 그럼에도 불구하고 대답 :)

Docker 및 배포 방법에 대한 학습은 실제로 코드 언어, 버전 제어 시스템, 컴파일러, 테스트 인프라 등 프로젝트 또는 팀 개발 환경의 일부로 만들어 비즈니스 요구 사항에 포함될 수 있습니다. 그 팀이나 프로젝트에서이 모든 것을 알고 사용해야하며, "자신의 것을 가져갈"수 없습니다 (대부분의 경우).

"개발자"가 실제로 대다수 또는 전체 개발 팀을 의미하는 경우 상황이 조금 더 복잡해집니다. 실제로 개발자를 지원하지 않고 개발 환경에서 도구를 푸시하는 것은 정말 어려울 것입니다. 팀의 기술 리더십에서 먼저 그러한 지지자를 만들 시간을 보내십시오.

사이드 참고 : 수 또한 고정 표시기 전문가가 각각 팀의 모든 개발자가 필요하지. 간단한 치트 시트 준비 명령으로 래핑 된 사전 설정된 사용 레시피를 통해 개발자는 내부 작업에 대해 너무 많이 알지 않고도 도커 기반 솔루션을 사용할 수 있습니다. 최종 제품의 구축 방법에 대한 모든 세부 사항을 모른 채 코드를 제공 할 수있는 것과 같습니다.

— 댄 코닐 레스 쿠
소스

또한 원하는 기술을 기반으로 제한을 줄이면서 시스템 관리자가 다른 모든 기술을 지원하는 데 어려움을 덜어줍니다. "dev"는 기술을 결정하므로 docker 환경을 구성하는 것은 그에게 달려 있습니다.

— DarkMukke

@DarkMukke "dev"가 항상 기술을 결정하는 것은 아닙니다. 대규모 dev 팀에서는 그 반대의 경우가 종종 있습니다. "dev"는 팀이 사용하는 모든 기술을 사용합니다. 팀 활동을 방해하지 않거나 부정적인 영향을 미치지 않으면 예외 가 허용 될 수 있습니다.

— Dan Cornilescu

나는 부분적으로 동의하지만, 대규모 (200+) 개발자 회사가 내가 설명한 방식으로 도커와 함께 작동하는 것을 보았습니다. 개발자 팀뿐만 아니라 그 위의 관리 직원이 개인적으로 선택한 문제라고 생각합니다. 괜찮은 devops가 있다면, dev가 필요로하는 docker의 양은 보통 사소합니다.

— DarkMukke

6

내가 당신에게 내 관점을 줄 것이다. 도커를 기꺼이 사용하고 이미 전문 지식을 쌓은 다른 개발자가 있으므로 개발자는 도커에주의해야합니다. 개발자와 개발자와 함께 DevOps 엔지니어의 역할을 맡게됩니다. 따라서 DevOps의 Ops 부분은 이제 전문 지식을 구축하는 것입니다.

요즘에는 테스트를 개발, 조정, 자동화, 작업 자동화 및 툴을 구축하여이 전체 패키지를 한 손으로 생산하고 모니터링 할 수있는 사람이 점점 더 많아 질 것입니다. 이들은 개발자 커뮤니티에서 도커 및 기타 도구를 밀고있는 사람들입니다.

또한 시장의 흐름은 가상화, 자동 확장, 자동화, 기계 학습 및 도커에 적합합니다. docker를 사용하는 것이 매우 중요합니다. 기업들은이 모든 책임을 맡은 한 사람에 대해 2 배를 기꺼이 지불하고 있으며 그러한 사람들에 대한 수요가있을 때 공급도 시작됩니다. 이것은 직원 고용주의 관점에서입니다.

기술적으로, 내가 일한 조직에는 별도의 개발 팀과 DevOps 팀이 있지만 배송에는 매우 밀접하게 작동합니다. DevOps 엔지니어와 개발자는 여기에서 대다수의 기술을 공유하므로 때때로 업무 협상이 있습니다.

개발자가 할 수있는 최소한의 일은 바이너리를 공유하는 것이지만, 바이너리가 도커 컨테이너 내부에서 실행되는 데 사용되고 도커의 작동 방식을 이해해야한다는 것을 이해해야합니다. kubes, swarms, mesos의 경우 개발자는 사용중인 것을 신경 쓰지 않을 수도 있지만 도커의 기본 사항은 개발자가 잘 이해해야하며 처음부터 다음과 같이 재사용을 위해 느슨하게 결합 된 응용 프로그램을 빌드하기위한 사고 방식이 있어야합니다 마이크로 서비스. 응용 프로그램이 해당 사고 방식 (도커의 기본 사항이 필요함)을 기반으로 구축 된 경우 DevOps 엔지니어는 자동 스케일링, 조정, 테스트, 배포 및 모니터링을 위해 응용 프로그램을 사용할 수 있습니다.

또한 대부분의 경우 하나의 크기가 모든 종류의 물건에 맞지 않습니다. 개발자는 도커 친화적 인 앱을 만드는 방법을 명확하게 알지 못하고 DevOps 엔지니어는 앱 빌드 프로세스의 내부를 잘 알지 못합니다. 따라서 대부분의 경우 조직은 이러한 작업을 모두 같은 사람에게 제공하여 작업 속도를 높이는 것을 선호합니다. 별도의 사항이있는 경우 앱을보다 미래적이고 도커 / 클라우드 / 스케일링 할 수 있도록 DevOps 팀에서 개발자 팀으로 지속적인 피드백 메커니즘이 필요합니다.

— 락 쉐이크
소스

5

Docker 또는 다른 컨테이너화 기술이 아닙니다.

Docker, rkt 등과 같은 컨테이너는 정적 바이너리와 유사한 방식으로 응용 프로그램을 제공하는 방법입니다. 내부에 필요한 모든 것이 포함 된 배포를 구축하고 있으며 최종 사용자에게는 런타임 이상의 것이 필요하지 않습니다.

이 솔루션은 Java의 팻 JAR과 유사합니다. 이론상 필요한 모든 것은 런타임 (JRE)이 사전 설치되어 있고 모든 것이 Just Works ™입니다.

개발자가 이해해야하는 이유 (그러한 도구를 작동하는 방법을 배울 필요가없고 필요한 이유 만) 오케스트레이션 도구를 사용하면 "전통적인"배포에 비해 몇 가지 이점이 있습니다.

애완 동물이 아닌 소

EngineYard는 그것에 관해 좋은 기사를 썼습니다. 요점은 서버가 죽을 때, 당신은 어깨를 으 and하고 새로운 것이 나타날 때까지 기다린다는 것입니다. 당신은 그것들을 소로 취급하고, 수십, 수백, 수천 마리의 달리기를하고, 사람이 쓰러 질 때 당신이나 당신의 클라이언트는 그 사실을 알고 있어야합니다.

오케스트레이션 도구는 클러스터에있는 모든 응용 프로그램 (포드 / 작업 등)의 상태를 모니터링하여 서버 중 하나가 응답을 멈춘 경우 (정지 된 후) 해당 서버에서 실행중인 모든 응용 프로그램을 다른 곳으로 자동으로 이동시킵니다.

더 나은 자원 활용

오케스트레이션 덕분에 하나의 서버에서 여러 애플리케이션을 실행할 수 있으며 오케 스트레이터가 리소스를 추적합니다. 필요할 때 응용 프로그램을 다시 정렬합니다.

불변 인프라

오케 스트레이터의 자동 장애 조치 처리 기능으로 클라우드에서 사용자 정의 이미지를 그대로 실행할 수 있습니다. 업데이트가 필요할 때 새 이미지를 작성하고 시작 이미지를 사용하도록 설정하고 실행하십시오. 모든 것이 당신을 위해 처리됩니다 :

새로운 구성으로 새 서버를 만듭니다.
실행중인 서버 하나를 종료하십시오.
오케 스트레이터는 모든 것을 다른 기계 (새로운 기계 포함)로 옮깁니다.
기존 서버가 남아 있으면 1로 이동하십시오.

더 간단한 조작

불충분 한 자원? 클러스터에 새 머신을 추가하십시오.
더 많은 응용 프로그램 인스턴스가 필요하십니까? 수를 늘리고 계속하십시오.
모니터링? 끝난.
로그 관리? 끝난.
비밀? 뭔지 맞춰봐.

TL; DR 요점은 Docker가 아니라 오케스트레이션입니다. Docker는 적절한 오케스트레이션에 필요한 tarball / fat JAR의 확장 버전입니다.

— 하울 레스
소스

이것이 제가 묻는 것입니다. 그리고 그것은 전체 질문에 관한 것입니다. 개발자가 더 나은 리소스 활용, 불변 인프라 및보다 단순한 운영에 관심을 가져야합니까? ... 더 나은 리소스 활용으로 이어질 비즈니스 요구 사항 및 코드 최적화를 제공하는 데 집중해야한다고 생각합니다. 도커조차도 잘못되거나 평균적으로 작성된 코드 인 경우 더 나은 활용에 도움이되지 않습니다. 비즈니스 요구 사항으로 인해 개발자가 더 빠르게 작업을 수행 할 수 있다는 사실을 받아들입니다. 그리고 이렇게하면 코드를 최적화 할 시간이 없습니다. 도커의 책임을 추가 해야하는 이유는 무엇입니까?

— Abhay Pai

문제는 테스트에서 구현, 마지막으로 배포에 이르기까지 전체 스택에 대한 개요를 제공함으로써 소프트웨어 사용 방법, 가장 중요한 사례, 충돌 원인을 확인할 수 있다는 것입니다. LOC를 작성하면 속도가 느려지지만 품질이 크게 향상됩니다. 장기 절약 시간

— Moritz

4

예를 들어 2014 년에 게시되고 귀하의 답변과 매우 일치하는 제목의 블로그 게시물에서 나온 몇 가지 주장이 있습니다.

새로운 기술을 환경에 훨씬 더 유연하게 주입

최종 테스트 코드를 커밋 한 다음 최종 프로덕션 서버에서 코드를 실행하는 데 여전히 큰 어려움이 있습니다. Docker는이 마지막 단계를 크게 단순화합니다.

Docker는 실행중인 Linux의 맛에 관계없이 레거시 OS를 유지하는 것이 간단합니다.

보낸 사람 : https://thenewstack.io/why-you-should-care-about-docker/

— 피터 머시킨
소스

나는 새로운 기술의 주입에 동의합니다. 그러나 그것에도 몇 가지 문제가 있습니다. 데이터베이스에 도커를 사용하는 것과 같습니다 ( percona.com/blog/2016/11/16/is-docker-for-your-database ). 현재로서는 안정적이지 않으며 아마도 미래에는 안정적 일 것입니다. 최선을 기대해 보자구. 어쨌든 CI / CD를 사용하여 테스트 된 코드를 생산에 적용 할 수 있습니다. 그렇다면 왜 도커입니까? 개발자는 우리가 어떤 OS를 사용하고 있는지 신경 쓰지 않습니다. 왜 그들은 처음부터 학습 도커를 귀찮게해야합니까? devops 삶을 더 쉽게 만들려면?

— Abhay Pai

우선 다음 "MVP"시나리오에 대해 생각합니다. dev는 환경을위한 새로운 구성 / 도구를 인프라 구성 요소 (imagemagick)로 시도합니다. Docker가 없으면이 정보를 잃어 버리거나 잊어 버리거나 다른 많은 작은 것들과 통신해야합니다. Dockerfile을 공유하는 것은 기계가 제공하는 작업 가능한 설정으로, Docker가없는 인프라에 설정을 수작업으로 작성하는 것조차 문서화보다 더 중요합니다. 꼭두각시로 갈 수도 있습니다. Docker의 좋은 점은 IMHO가 자체 포함 시나리오를 허용하는 방법입니다.

— 피터 Muryshkin

동의했다. 그러나 오케스트레이션 중에 문제가 발생합니다. 모범 사례를 준수하고 비즈니스 요구 사항을 충족 시키려면 개발자가 도커 오케스트레이션에 대한 전문 지식이 있어야합니다. 개발자가 서비스로 imagemagick을 필요로하는 시나리오를 고려하십시오. 이제 도커 파일을 작성하는 동안 도커 이미지에 설치할 수있는 패키지를 완전히 제어 할 수 있습니다. 도커 로그 대신 sshd를 설치하여 도커에 ssh를 설치하면 어떻게됩니까? 비즈니스 로직과 관련이 없지만 보안을 손상시키는 도구를 설치하면 어떻게됩니까? 개발자는 도커 전문 지식이 필요합니까?

— Abhay Pai

그러나 소켓 기반 백도어를 구현하면 어떨까요? 도커는 내가 생각하는 기업 방화벽을 대체하지 않습니다

— Peter Muryshkin

진실. 그러나 그것은 어쨌든 개발자의 악의적 인 의도 일 것입니다. 도커이거나도 커가 없어야합니다. 그러나도 커가 개발자에게 소개되면 적절한 지식이 없기 때문에 사고가 발생할 수 있습니다. 사고와 합병증을 유발할 수있는 도커를 배우는 데 왜 귀찮게해야 하는가 (오케 스트레이터도 복잡성을 추가 할 것임)? 제 질문은 신경 쓰지 마십시오. 도 커도 좋아합니다. 그러나 개발자의 관점을 이해하려고합니다. 저는 지난 3 년간 개발자로 일해 왔으며 이제는 DevOps 엔지니어입니다.

— Abhay Pai

4

docker 컨테이너에서 프로덕션을 실행하는 경우 해당 컨테이너를 실행하는 동일한 개발자가 컨테이너를 만드는 것이 중요합니다. 어떤 외부 의존성이 필요한지 더 잘 알고있는 사람은 누구일까요?

또한 CD의 모든 단계에서 파이프 라인이 실패 할 수 있습니다. 특히 도커 이미지 빌드 단계 인 경우에는 누락 된 파일이거나 필요한 lib 일 수 있습니다.

직장에서 우리는 앱을 제공하기 위해 dockerfile을 빌드하는 기본 사항을 설명하는 docker에 모든 개발자를 소개했으며 파이프 라인을 쉽게 만들었으므로 이름과 dockerfile 만 추가하면 앱이 자동으로 빌드됩니다. 그것을 실행하는 기술에 관계없이 다음 푸시.

Docker 빠른 시작은 devOps 팀이 개발자가 배포판을 선택하도록 가이드 한 후 (많은 사람들이와 같은 것을 알지 못함) 실제로 그렇게하기위한 훌륭한 소개 alpine입니다.

우리의 임무는 그들에게 도구에 쉽게 접근 할 수 있도록하고 나머지는 무언가 잘못되었을 때 수정할 수 있도록하는 것입니다. Docker는 실제로 개발 프로세스의 일부이며 devOps 팀은 우리의 요구에 맞는 Docker 이미지를 제공하기 때문에 새로운 앱을 만들고 도움없이 배포하는 데 몇 분 밖에 걸리지 않습니다.

— Juub
소스

따라서 개발자에 따르면 프로젝트에서 외부 의존성을 요구하는 경우에만 프로젝트에서 도커를 사용해야합니다. Docker는 개발자에게 적용했거나 시원하다고 생각하기 때문에 개발 프로세스의 일부가 된 것 같습니다. 또한 오케스트레이션 중에 문제가 발생합니다. 그들은 떼, kubernetes 또는 mesos와 같은 조정자를 배워야합니까? 이 모든 오케스트레이션의 구현은 다릅니다. 구현이 잘못되어 오케스트레이션이 충돌하면 어떻게됩니까? 누구를 비난받을 것인가? 추신 : 내 질문은 신경 쓰지 마십시오. 나는 단지 devli의 옹호자를하고있다. 나도 도커를 좋아한다 :)

— Abhay Pai

2

Docker는 많은 언론과 블로그 언급을 얻었으며 개발자는이를 사용하는 데 관심이 있습니다. 어떤 사람들에게는 새로운 기술을 가지고 놀거나 일이 어떻게 작동하는지 이해하는 것이 흥미 롭습니다. 다른 사람들에게는 이력서에 키워드를 추가하고자합니다. 어느 쪽이든, 더 많은 개발자가 일이 어떻게 작동하고 어떻게 배포되는지에 대해 알고 있으면 나중에 놀라지 않을 것입니다. 내가 본 것에서 이것에 대해 이미 상당한 관심이 있기 때문에 더 장려하는 것이 어렵지 않아야합니다.

— 병아리
소스

0

글쎄, 테스트에 VM을 사용한 적이 있다면 컨테이너를 사용하려고 할 수도 있고 도커는 실제로 테스트에 큰 재료이며 LXC 대신 사용하는 것이 훨씬 간단합니다. :)

— YV
소스

동의했다. 도커를 사용하지 않거나 다양한 오케스트레이션 도구입니다. 나도 그들을 사랑해. 내가 이해하려고하는 것은 간단합니다. 애플리케이션의 컨테이너화를 소유 한 사람입니다. 개발자? 아니면 DevOps? 아니면 둘다 ? 그렇다면 둘 다 얼마나 기여해야합니까? 도커 또는 도커 오케스트레이션으로 인해 문제가 발생하면 누가 책임을 져야합니까? 코드 효율성 대 개발자의 삶을 편하게 돕습니다. 내 질문은 기술 자체보다는 개인의 역할에 대한 경향이 있습니다.

— Abhay Pai