무대 뒤에서. 강좌는 어떻게 만들어지나요?

참가자가 코스 또는 집중 코스에 참여합니다. 그는 질서정연하게 늘어선 기술 지원, 깔끔하게 배선된 전원 케이블, 강의실의 체커보드 레이아웃, 밝은 그림 및 슬라이드 다이어그램을 봅니다. 농담과 미소를 지닌 화자는 당신이 이해할 시간을 가질 수 있도록 정보를 제공합니다. 스탠드가 설치되어 있으며 연습 작업은 때때로 기술 직원의 도움이 필요한 경우를 제외하고는 간단합니다. 지원하다.

또한 같은 생각을 가진 사람들과의 커피 휴식, 밝고 활기찬 분위기, 경험 교환, 연사에 대한 가장 예상치 못한 질문도 있습니다. 매뉴얼에서는 찾을 수 없지만 실제로는 찾을 수 있는 답변과 정보입니다.

정확히 이렇게 보이도록 만드는 데 얼마나 많은 시간과 노력, 신경이 필요했다고 생각하시나요?

처음부터 많은 Slurm 과정 생성을 목격하고 적극적으로 참여한 Southbridge의 인증된 Kubernetes 관리자이자 엔지니어/팀 리더인 Volodya Guryanov에게 감사드립니다.

그는 코스 창조의 밑바닥인 복잡성과 가시가 많은 갈퀴, 통찰력, 예상치 못한 해결책을 보았습니다. 그리고 Slurm Basic 및 Slurm Mega와 같이 이미 친숙한 Kubernetes 집약적 기능도 있습니다. 그리고 새롭게 개정된 강좌 Slurm DevOps:도구 및 요령, 이는 거침없이 다가오고 있으며 19월 XNUMX일에 시작됩니다.

하지만 가사가 충분하다면 이야기 자체로 넘어가겠습니다. 몇 가지 집중적인 주제를 통해 완전히 자급자족하고 다각적인 주제를 다루는 방법 도커 코스. 그럼 "아주 먼 옛날 은하계에서..."처럼 코스가 어떻게 만들어지고 발전하는지 이야기를 시작하겠습니다.

배후에는 무엇이 있나요?

코스를 만드는 방법과 모든 것이 어디서 시작되는지 묻는다면 저는 “모든 것은 아이디어에서 시작됩니다.”라고 간단히 대답할 것입니다.

일반적으로 아이디어는 어딘가에서 나옵니다. "어떤 주제로 수업을 진행해야 할까요?"라는 질문이 나올 때까지 우리는 지하실에 수갑을 채우고 앉아 있지 않습니다. 아이디어는 외부 소스로부터 저절로 어딘가에서 나옵니다. 때때로 사람들은 "이러한 특정 기술에 대해 무엇을 알고 있습니까? "라고 적극적으로 묻기 시작합니다. 또는 Docker의 경우 집중 코스 시간에 맞추는 것이 불가능했습니다. 집중 코스 중에 무언가를 말할 시간을 갖기 위해 그는 분명히 밖으로 나가야 했습니다.

이것이 아이디어가 나타나는 방식입니다.

발표 후, 제 생각에는 가장 어려운 순간이 시작됩니다. 이 과정에 포함할 내용을 일반적으로 이해하는 것은 연사가 모든 회의를 위해 준비하는 방법과 매우 유사합니다.

주제를 선택한 것 같으면서 다음과 같이 생각할 때 한 가지 큰 고통이 있습니다. “그것에 대해 내가 무엇을 말할 수 있을까? 이건 너무 단순하고 뻔한 일이고 모두가 알고 있는 사실이다.”

그러나 실제로는 전혀 그렇지 않습니다. 그리고 나는 개인적으로 여러 곳에서 여러분에게, 여러분의 말을 듣거나 강좌를 들으러 오는 사람들에게 명백해 보이는 것이 전혀 명백하지 않다고 말합니다. 그리고 여기에서 과정에 무엇을 포함할지에 대한 작업과 내부 갈등이 발생합니다. 결과적으로, 우리는 코스가 무엇에 관한 것인지, 이렇게 대대적으로 설명하는 장의 목록을 얻게 됩니다.

그런 다음 간단한 일상적인 작업이 시작됩니다.

• 재료 선택
• IT 세계는 이제 일종의 우주적 속도로 발전하고 있으므로 현재 버전에 대한 문서를 주의 깊게 읽으십시오. 무언가를 작업하고 이에 대한 강좌를 만들더라도 문서로 가서 거기에 무엇이 새로운지, 무엇이 흥미로운지, 무엇을 언급하는 것이 특히 유용한지 확인해야 합니다.
• 그리고 일반적으로 대부분의 주제가 이미 다루어져 있고 비디오를 녹화하고 제작에 착수하는 등의 과정의 특정 뼈대가 나타납니다.
• 그러나 실제로는 아닙니다. 힘든 작업이 시작되지만 코스 작성자가 아니라 테스트하는 사람들을위한 것입니다. 일반적으로 알파 테스터는 기술 지원을 담당하며, 먼저 구문 및 문법 오류가 있는지 과정을 교정합니다. 둘째, 완전히 불분명하고 이해할 수없는 곳이 있으면 그들은 우리를 막대기로 고통스럽게 때리고 맹세합니다. 텍스트에 몇 페이지에 걸쳐 복잡하게 구성된 하위 문장이 나타나거나 명백한 넌센스가 나타날 때. 그들은 그것을 모두 읽고 주의 깊게 살펴봅니다.
• 그런 다음 연습 테스트 단계가 시작됩니다. 여기서는 작동하지 않는 몇 가지 명백한 항목도 포착되고 그다지 흥미롭지 않기 때문에 더 어렵게 만들 수 있는 순간이 표시됩니다. 단지 앉아서 복사하는 것만으로도 매우 흥미로운 장소가 식별됩니다. 어렵고 우리는 이 과정을 수강할 사람들에게 바라는 것이 많습니다. 그런 다음 다음과 같은 권장 사항이 제공됩니다. "여러분, 여기서 더 간단하게 만들면 인식하기가 더 쉽고 더 많은 이점이 있을 것입니다."
• 이 정도 작업을 마치고 영상과 관련된 부분을 작성해보니 모든 게 괜찮은 것 같습니다. 그리고 이미 이 강좌를 제작하고 광고하기 위해 기부할 수 있습니다. 하지만 다시 말하지만, 아직은 너무 이르습니다. 최근 우리는 자신을 조금 신뢰하지 않고 원칙적으로 피드백을 통해 더 많은 작업을 시작했기 때문입니다. 베타 테스트와 같은 것이 있습니다. 이것은 우리 회사와 어떤 식으로든 연결되지 않은 외부인으로부터 사람들을 초대하는 경우이며, 일부 혜택의 경우 코스의 모든 부분, 비디오, 텍스트, 실제 작업을 보여줍니다. 자료의 품질과 자료의 접근성을 평가하고 강좌를 최대한 좋게 만드는 데 도움을 주었습니다.
• 그리고 그러한 반복이 여러 번 진행되면 스피커, 기술 지원 형태의 알파 테스트, 베타 테스트, 개선이 이루어집니다. 그런 다음 기술 지원, 베타 테스트, 개선 등 모든 것이 다시 시작됩니다.
• 그리고 어느 시점에서 모든 사람이 좋아하는지 확인하는 것은 완전히 비현실적이기 때문에 수정이 끝났거나 일부 과감한 결정이 내려졌다는 것을 이해하게 됩니다. 특정 장소에 대한 많은 댓글이 중요할 경우 문제가 발생했기 때문에 전역적으로 다시 실행하세요.
• 그런 다음 사소한 편집을 해야 할 때가 왔습니다. 문장이 아주 멋지게 구성되지 않은 곳, 누군가가 글꼴 14,5를 좋아하지 않지만 15,7을 원하는 곳입니다.
• 이런 댓글이 남아 있으면 그걸로 됐고, 어느 정도 강좌가 열리면 정식 판매가 시작되는 거죠.

그리고 언뜻보기에 코스를 만드는 짧고 간단한 작업은 전혀 간단하지 않고 엄청나게 오랜 시간이 걸립니다.

그리고 강좌가 공개되더라도 강좌 작업이 끝나지 않는다는 또 다른 중요한 점이 있습니다. 우선 특정 부분에 남겨진 댓글을 꼼꼼히 읽어봅니다. 그리고 우리가 모든 노력을 기울였음에도 불구하고 일부 결함은 여전히 ​​확인되고 일부 실수는 실시간으로 수정 및 개선되어 이후의 각 사용자가 더 나은 서비스를 받을 수 있습니다.

각 코스에는 자체 제품 소유자가 있는데, 그는 일반적인 개념을 정의하는 것 외에도 마감일을 확인하고 코스를 완전히 다시 작성해야 할 때가 오면 여백에 메모를 합니다. 왜냐하면 XNUMX년 후에는 또는 심지어 XNUMX년이 지나도 우리가 말하는 것 중 일부는 단지 그것이 도덕적으로 쓸모없어질 것이기 때문에 관련성이 없어질 것입니다. 제품 소유자는 사람들이 어떤 점이 명확하지 않은지, 어떤 작업이 매우 어려워 보이는지, 반대로 어떤 작업이 매우 단순해 보이는지 여백에 메모합니다. 그리고 일종의 리팩토링 중에 코스를 다시 기록할 때 이 모든 것이 고려되므로 글로벌 코스의 각 반복이 더 좋고, 더 편리하고 편안해집니다.

코스는 이렇게 나옵니다.

Docker 과정은 어떻게 탄생했나요?

이것은 우리에게 별개의, 심지어 특이한 주제입니다. 한편으로는 많은 온라인 학교에서 이를 제공하기 때문에 우리는 이를 계획하지 않았습니다. 반면에 그 자신은 자유를 요구했고 Kubernetes에서 IT 전문가를 교육한다는 개념에서 논리적인 위치를 찾았습니다.

매우 전 세계적으로 말하면 처음에는 모든 것이 Kubernetes에 대한 과정으로 시작되었습니다. 제 생각에는 첫 번째 Slurm 이후 막 시작되었습니다. 피드백을 수집한 결과 많은 사람들이 Docker에 대한 추가 내용을 다른 곳에서 읽고 싶어하며 일반적으로 많은 사람들이 그것이 무엇인지 모르고 Kubernetes의 기본 과정에 오는 것을 확인했습니다. 도커.

따라서 두 번째 Slurm에서는 코스를 만들었습니다. 아니 오히려 코스가 아니라 Docker에 대한 두 장을 만들었습니다. 집중 치료를받는 사람들이 박탈감을 느끼지 않고 일반적으로 무슨 일이 일어나고 있는지 이해할 수 있도록 가장 기본적인 몇 가지 사항을 말한 곳입니다.

그리고 사건은 대략 이런 식으로 전개되었습니다. 재료의 양이 늘어나서 3일 만에 피팅이 중단되었습니다. 그리고 논리적이고 분명한 아이디어가 나타났습니다. Slurm Basic에서 다루는 내용을 Kubernetes에 대한 집중 과정을 수강하기 전에 Docker에 대해 보고 싶은 사람들을 보낼 수 있는 일종의 소규모 과정으로 바꾸는 것이 어떻겠습니까?

Slurm Junior는 실제로 이러한 여러 기본 코스의 조합입니다. 그 결과 Docker 과정은 Slurm Junior의 일부가 되었습니다. 즉, 이것은 이전의 제로 단계입니다 기본 и 메가. 그리고 아주 기본적인 추상화만 있었습니다.

어느 시점부터 사람들은 이렇게 묻기 시작했습니다. “얘들아, 이거 다 좋다. 집중 코스에서 말하는 내용을 이해하기에 충분하다. Docker가 무엇을 할 수 있는지, 어떻게 작업하는지, 그것이 무엇인지에 대한 자세한 내용은 어디서 읽을 수 있나요?” 그래서 그것을 바로잡기 위한 아이디어가 떠올랐어요 Docker에 대한 전체 과정, 첫째로 Kubernetes를 사용하여 Slurm에 오는 사람들은 여전히 ​​Slurm으로 보낼 수 있고 다른 한편으로는 이 개발 단계에서 Kubernetes에 관심조차 없는 사람들을 위해 보낼 수 있습니다. IT 전문가가 Docker에 대한 우리 과정을 시청하고 순수 Docker를 사용하여 진화의 길을 시작할 수 있도록 말이죠. 그래서 우리는 본격적인 완전한 과정을 갖게 되었고, 이 과정을 시청하고 한동안 순수 Docker로 작업한 많은 사람들이 Kubernetes나 다른 오케스트레이션 시스템이 필요한 수준으로 성장했습니다. 그리고 그들은 특히 우리에게 왔습니다.

때때로 "이제 어떤 사람들에게 Kubernetes가 필요하지 않을까?"라는 질문이 제기됩니다. 하지만 이 질문은 사람에 대한 질문이 아니라 오히려 기업에 대한 질문입니다. 여기에서는 Kubernetes가 잘 맞는 특정 사례와 잘 해결되는 작업이 있다는 점을 이해해야 합니다. 그러나 반대로 Kubernetes가 추가 고통과 추가 고통을 야기할 때 Kubernetes를 사용하는 몇 가지 시나리오가 있습니다. 그러므로 그것은 사람에 달려 있는 것이 아니라, 어떤 회사가 얼마나 오랫동안 개발을 해왔는지에 달려 있습니다.

예를 들어, 일부 끔찍한 레거시 모놀리스는 이점보다 더 많은 문제를 야기하므로 Kubernetes에 밀어넣어서는 안 됩니다. 또는 예를 들어 소규모 프로젝트인 경우 부하가 적거나 원칙적으로 돈과 자원이 많지 않습니다. Kubernetes로 끌어다 놓을 필요가 없습니다.

그리고 일반적으로 많은 사람들이 이미 말했듯이 "Kubernetes가 필요한가요?"라는 질문을 한다면 아마도 필요하지 않을 가능성이 높습니다. 제 생각에는 Pasha Selivanov가 누가 처음으로 생각해 냈는지 기억이 나지 않습니다. 나는 이에 100% 동의한다. 그리고 Kubernetes로 성장해야 합니다. 나에게 Kubernetes가 필요하고 우리 회사에도 Kubernetes가 필요하다는 것이 이미 분명해지고 이것이 이러한 문제를 해결하는 데 도움이 될 때 가서 배우고 설정하는 방법을 정확히 알아내는 것이 아마도 합리적일 것입니다. 잘 작동하므로 Kubernetes로 전환하는 과정이 그다지 고통스럽지 않습니다.

일부 어린이 질병과 일부 단순한 것, 심지어 매우 단순하지 않은 것조차도 우리에게서 특별히 발견될 수 있으며 귀하의 갈퀴와 고통을 겪지 않습니다.

많은 기업이 처음에는 컨테이너화 없이 일종의 인프라만 있었던 것과 똑같은 방식으로 진행되었습니다. 그러다가 모든 것을 관리하기 어려워지는 지점에 이르렀고 Docker로 전환했으며 어느 시점에서는 Docker의 프레임워크와 그것이 제공하는 것 내에서 비좁아지는 지점까지 성장했습니다. 그리고 그들은 주변에 무엇이 있는지, 어떤 시스템이 이러한 문제를 해결하는지, 특히 Kubernetes를 살펴보기 시작했습니다. 이는 순수 Docker가 혼잡해지고 기능이 부족할 때 문제를 해결할 수 있는 시스템 중 하나입니다. 그들은 아래에서 위로 한 단계씩 나아가며, 이 기술로는 충분하지 않다는 것을 이해하고 다음 단계로 나아갑니다. 그들은 무언가를 사용했고 그것이 다시 부족해졌고 계속 나아갔습니다.

이것은 의식적인 선택이며 매우 멋지다.

일반적으로 우리 시스템은 매우 아름답게 구축되어 있습니다. 예를 들어, 도커 코스, 비디오 강좌를 통해서도 마찬가지입니다. 그런 다음 docker 이후에 진행됩니다. 기본 쿠버네티스, 그 다음에 메가 쿠버네티스, 그 다음에 세프. 모든 것이 논리적으로 정렬됩니다. 사람이 지나가고 탄탄한 직업이 나타납니다.

원칙적으로 일련의 과정을 통해 많은 사례, 심지어 현대적인 사례까지 다룰 수 있습니다. 여전히 회색 영역으로 남아 있는 영역이 있습니다. 이러한 회색 영역을 닫을 수 있는 강좌를 곧 만들 수 있기를 바랍니다. 특히 보안에 관한 내용을 생각해 낼 수 있을 것입니다. 왜냐하면 이것이 매우 관련성이 높아지고 있기 때문입니다.

간단히 말해서, 닫으면 매우 좋을 몇 가지 회색 영역이 있으므로 완전하고 완전한 그림이 될 것입니다. 사람들이 올 수 있고 Kubernetes 자체가 레고 생성자와 같듯이 사용자는 다른 것을 만들 수 있습니다. 여전히 충분하지 않은 경우 수집합니다. 사람들이 여기에서 필요한 것이 무엇인지 이해할 수 있도록 우리 코스와 동일하게 보충하고 우리 코스에서 일종의 퍼즐, 일종의 구성 세트를 조립해야 합니다.

일반적으로 정확하고 정직한 질문인 "지금 누가 활성 Docker 교육 과정을 이용할 수 있나요?"라고 자문한다면 다음과 같습니다.

• 이제 막 입문하기 시작한 학생들을 위한 것입니다.
• 테스트 부서 직원.
• 실제로 Docker를 사용하지 않을 뿐만 아니라 이러한 기술에 대해 들어본 적도 없고 원칙적으로 사용 방법도 모르는 회사가 많이 있습니다. 그리고 저는 상트페테르부르크에 있는 여러 대기업을 알고 있습니다. 그들은 수년 동안 발전해 왔으며 일부 오래된 기술을 사용하여 이러한 방향으로 움직이고 있습니다. 특히, 그러한 회사의 경우, 그러한 회사의 엔지니어에게 이 과정은 매우 흥미로울 수 있습니다. 첫째, 이 기술에 빠르게 몰입할 수 있게 하고, 두 번째로 모든 것을 이해하는 여러 엔지니어가 등장하자마자 이를 회사로 가져와 회사 내에서 이러한 문화와 방향을 발전시킬 수 있습니다.
• 내 생각에 이 과정은 이미 docker로 작업한 사람들에게 여전히 유용할 수 있지만 "한 번, 두 번 수행" 스타일을 사용하는 경우는 거의 없으며 이제 그들은 어떻게든 동일한 Kubernetes와 상호 작용하게 될 것입니다. docker가 무엇인지, 어떻게 실행하는지에 대한 매우 피상적인 지식을 갖고 있지만 동시에 내부에서 어떻게 작동하는지 모르는 경우, 그들에게 특정 의무를 부과합니다. 그렇다면 이 과정은 지식을 체계화하고 심화하는 데 매우 적합합니다.

그러나 다음과 같은 수준의 지식이 있다면 "동일한 Docker 파일을 올바르게 작성하는 방법을 모릅니다. 네임스페이스가 무엇인지, 컨테이너가 어떻게 작동하는지, 운영 체제 수준에서 실제로 어떻게 구현되는지 상상할 수 있습니다." 우리에게 갈 필요가 전혀 없습니다. 새로운 것을 배우지 못할 것이며 지출 한 돈과 시간에 대해 조금 슬퍼하게 될 것입니다.

우리 과정의 장점을 공식화하면 다음과 같습니다.

• 우리는 존재하는 이론적 부분을 이해할 뿐만 아니라, 그것이 왜 필요한지, 앞으로 어떻게 사용할 것인지를 이해할 수 있도록 충분한 수의 실제 사례로 이 과정을 만들려고 노력했습니다.
• 어디에서도 거의 발견되지 않는 여러 섹션이 있으며 일반적으로 해당 섹션에는 그다지 많은 자료가 없습니다. 이는 Docker와 운영 체제의 상호 작용과 조금 다르게 관련되어 있습니다. Docker는 컨테이너화 시스템을 구현하기 위해 운영 체제에서 어떤 메커니즘을 취했으며 이를 통해 Linux 운영 체제 내에서 컨테이너를 실행하는 전체 문제에 대한 더 깊은 이해를 제공합니다. 작동 방식, 운영 체제 내부, 외부 등에서 서로 상호 작용하는 방식.

이것은 아주 드물게 발생하는 정말 깊은 모습이며 동시에 제 생각에는 매우 중요합니다. 어떤 기술을 잘 이해하고 그로부터 무엇을 기대할 수 있는지 이해하려면 최소한 낮은 수준에서 어떻게 작동하는지에 대한 일반적인 아이디어가 있어야 합니다.

우리 과정에서는 이것이 운영 체제 관점에서 어떻게 작동하는지 보여주고 설명합니다. 한편, 모든 컨테이너화 시스템은 동일한 운영 체제 메커니즘을 사용합니다. 반면에 그들은 docker와 같은 Linux 운영 체제에 있는 것을 사용합니다. 다른 컨테이너화 시스템은 새로운 것을 내놓지 않았습니다. 그들은 이미 Linux에 있는 것을 가져다가 신속하게 호출하고 실행하거나 어떻게든 상호 작용할 수 있는 편리한 래퍼를 작성했습니다. 동일한 Docker는 운영 체제와 명령줄 사이에 매우 큰 계층이 아니며 컨테이너를 생성하기 위해 엄청난 양의 명령이나 일종의 C 코드를 작성할 수 없지만 다음을 입력하여 이를 수행할 수 있는 일종의 유틸리티입니다. 터미널에 몇 줄.

그리고 한 가지 더, Docker에 관해 구체적으로 이야기한다면 Docker가 실제로 IT 세계에 가져온 것은 표준입니다. 애플리케이션 시작 방법, 작동 방식, 로그 요구 사항, 확장 요구 사항, 애플리케이션 자체 구성.

여러 면에서 docker는 표준에 관한 것입니다.

표준도 Kubernetes로 이동하고 있으며 정확히 동일한 표준이 있습니다. Docker에서 애플리케이션을 잘 실행하는 방법을 안다면 99%의 경우 Kubernetes 내에서도 잘 작동할 것입니다.

Docker 과정이 어떻게 만들어졌는지 뿐만 아니라 다른 과정에도 관심이 있고, 실용적인 관점에서 과정 자체에도 관심이 있다면, 5000월 30일까지 XNUMX루블의 선주문 할인으로 구매할 수 있는 시간이 아직 남아 있습니다.

우리는 당신을 만나서 기뻐할 것입니다!

출처 : habr.com