Một người tham gia đến một khóa học hoặc khóa học chuyên sâu. Anh nhìn thấy những dãy hỗ trợ kỹ thuật được sắp xếp ngăn nắp, những dây cáp điện được định tuyến gọn gàng, cách bố trí bàn cờ của giảng đường, những bức tranh tươi sáng và những sơ đồ trình chiếu. Những người nói với những câu chuyện cười và nụ cười đưa ra thông tin theo cách mà bạn chỉ cần có thời gian để hiểu. Khán đài đã được dựng lên, nhiệm vụ tập luyện chỉ như bay khỏi đầu ngón tay, ngoại trừ việc đôi khi bạn cần đến sự trợ giúp của nhân viên kỹ thuật. ủng hộ.
Và còn có những giờ giải lao cà phê cùng những người cùng chí hướng, không khí vui vẻ, tràn đầy năng lượng, trao đổi kinh nghiệm, những câu hỏi bất ngờ nhất dành cho diễn giả. Cả câu trả lời và thông tin mà bạn sẽ không tìm thấy trong sách hướng dẫn mà chỉ có trong thực tế.
Bạn nghĩ mình đã mất bao nhiêu thời gian, công sức và thần kinh để làm được nó trông giống hệt như thế này?
Xin cảm ơn Volodya Guryanov, quản trị viên Kubernetes và kỹ sư/trưởng nhóm được chứng nhận tại Southbridge, người đã chứng kiến và tích cực tham gia vào việc tạo ra nhiều khóa học Slurm ngay từ đầu.
Tất nhiên, anh ấy đã nhìn thấy nền tảng của sự sáng tạo—sự phức tạp và những khó khăn gai góc, những hiểu biết sâu sắc và những giải pháp bất ngờ. Và các chuyên sâu Kubernetes vốn đã quen thuộc, chẳng hạn như Slurm Basic và Slurm Mega. Và một khóa học mới, được sửa đổi phần lớn , chắc chắn đang đến gần và sẽ bắt đầu vào ngày 19 tháng XNUMX.
Nhưng có lẽ lời bài hát đã đủ rồi, chúng ta hãy chuyển sang câu chuyện. Làm thế nào từ một vài chủ đề chuyên sâu trở nên hoàn toàn tự túc và đa diện . Vì vậy, tôi sẽ bắt đầu câu chuyện về cách các khóa học được tạo ra và phát triển - giống như “Cách đây đã lâu ở một thiên hà rất xa…”
Đằng sau hậu trường là gì?
Nếu bạn hỏi chúng tôi tổ chức các khóa học như thế nào và bắt đầu từ đâu, tôi sẽ chỉ trả lời “Tất cả đều bắt đầu từ một ý tưởng”.
Thông thường, ý tưởng đến từ đâu đó - chúng tôi không ngồi bị còng tay dưới tầng hầm cho đến khi nghĩ ra: “Chúng ta nên tham gia một khóa học về chủ đề nào?” Ý tưởng đến từ đâu đó từ các nguồn bên ngoài. Đôi khi mọi người bắt đầu chủ động hỏi: "Bạn biết gì về một công nghệ cụ thể như vậy?" Hoặc với Docker thì không thể sắp xếp thời gian cho khóa học chuyên sâu của anh ấy - rõ ràng anh ấy phải được đưa ra ngoài để có thời gian nói điều gì đó trong khóa học chuyên sâu.
Đây là cách một ý tưởng xuất hiện.
Theo tôi, sau khi nó được công bố, thời điểm khó khăn nhất bắt đầu - để hiểu tổng thể những gì cần đưa vào khóa học này - điều này rất giống với cách các diễn giả chuẩn bị cho bất kỳ hội nghị nào.
Có một nỗi đau chính khi bạn dường như đã chọn một chủ đề và nghĩ: “Tôi có thể nói gì về nó? Điều này quá đơn giản, điều này là hiển nhiên, điều này ai cũng biết ”.
Nhưng trên thực tế thì hoàn toàn không phải như vậy. Và cá nhân tôi nói ở nhiều nơi rằng những gì có vẻ hiển nhiên đối với bạn, đối với những người đến nghe bạn hoặc tham gia một khóa học, lại không hề hiển nhiên chút nào. Và ở đây nảy sinh một lượng lớn công việc và xung đột nội bộ như vậy về việc nên đưa những gì vào khóa học. Kết quả là, chúng ta có được một danh sách các chương với những điểm nhấn lớn như vậy, khóa học sẽ nói về nội dung gì.
Và sau đó công việc thường ngày đơn giản bắt đầu:
- Lựa chọn vật liệu
- Hãy đọc kỹ tài liệu dành cho phiên bản hiện tại, vì thế giới CNTT hiện đang phát triển với tốc độ chóng mặt. Ngay cả khi bạn làm việc với một thứ gì đó và tham gia một khóa học về nó, bạn vẫn phải truy cập vào tài liệu và xem có gì mới ở đó, có gì thú vị để nói, những gì có thể đặc biệt hữu ích để đề cập.
- Và một khung nhất định của khóa học xuất hiện, trong đó hầu hết các chủ đề nói chung đều đã được đề cập đến và dường như bất cứ thứ gì ở đó - hãy quay video và đưa chúng vào sản xuất.
- Nhưng trên thực tế là không, khi đó công việc khó khăn mới bắt đầu, không phải đối với các tác giả của khóa học mà đối với những người kiểm tra. Thông thường, những người thử nghiệm alpha của chúng tôi là người hỗ trợ kỹ thuật, trước hết là hiệu đính các khóa học để tìm bất kỳ lỗi cú pháp và ngữ pháp nào. Thứ hai, họ dùng gậy đánh chúng tôi một cách đau đớn và chửi thề khi có một số chỗ hoàn toàn không rõ ràng, khó hiểu. Khi một số câu phụ được viết phức tạp kéo dài vài trang hoặc vô nghĩa rõ ràng xuất hiện trong văn bản. Họ đọc tất cả, tìm kiếm nó.
- Sau đó, giai đoạn kiểm tra thực hành bắt đầu, trong đó một số điều rõ ràng là không hoạt động cũng bị phát hiện và một số khoảnh khắc được hiển thị có thể trở nên khó khăn hơn vì nó trở nên không thú vị lắm - chỉ cần ngồi và sao chép - và các địa điểm được xác định ở vị trí rất quan trọng. khó khăn và chúng tôi có rất nhiều việc phải làm mà chúng tôi muốn từ những người sẽ tham gia khóa học này. Và sau đó có những khuyến nghị: “Các bạn, hãy làm cho nó đơn giản hơn ở đây, sẽ dễ nhận biết hơn và sẽ có nhiều lợi ích hơn từ nó”.
- Sau khi hoàn thành khối lượng công việc này, phần liên quan đến video được viết ra, mọi thứ dường như đều ổn. Và bạn đã có thể quyên góp nó để sản xuất, quảng cáo khóa học này. Nhưng một lần nữa, không, còn quá sớm - bởi vì gần đây chúng tôi đã không còn tin tưởng vào bản thân một chút nữa và về nguyên tắc, chúng tôi đã bắt đầu làm việc nhiều hơn với các phản hồi. Có một thứ gọi là thử nghiệm beta - đây là khi mọi người được mời từ người ngoài, không kết nối với công ty của chúng tôi dưới bất kỳ hình thức nào và đối với một số tính năng thú vị, họ được xem tất cả các phần của khóa học, video, văn bản, nhiệm vụ thực tế để họ đánh giá chất lượng của tài liệu, khả năng tiếp cận của tài liệu và giúp chúng tôi thực hiện khóa học tốt nhất có thể.
- Và khi một số lần lặp lại như vậy được thực hiện, các diễn giả sẽ thử nghiệm alpha dưới hình thức hỗ trợ kỹ thuật, thử nghiệm beta, cải tiến. Và sau đó mọi thứ lại bắt đầu lại - hỗ trợ kỹ thuật, thử nghiệm beta, cải tiến.
- Và tại một thời điểm nhất định, người ta hiểu rằng hoặc là chúng tôi đã hoàn thành việc sửa đổi, bởi vì việc đảm bảo rằng mọi người đều thích nó hoặc một số quyết định quyết liệt được đưa ra là hoàn toàn phi thực tế. Khi có nhiều nhận xét ở một số vị trí nhất định là quan trọng, hãy làm lại chúng trên toàn cầu vì đã xảy ra lỗi.
- Sau đó, đến lúc phải chỉnh sửa nhỏ - ở đâu đó câu văn được xây dựng không đẹp lắm, ở đâu đó có người không thích phông chữ 14,5 nhưng lại thích 15,7.
- Khi còn lại kiểu bình luận này thì thế là xong, khóa học ít nhiều sẽ mở ra, đợt mở bán chính thức bắt đầu.
Và thoạt nhìn, nhiệm vụ ngắn gọn và đơn giản là tạo một khóa học hóa ra không hề đơn giản chút nào và mất một thời gian dài đến khó tin.
Và có một điểm quan trọng khác là công việc với khóa học không kết thúc khi khóa học được phát hành. Đầu tiên, chúng tôi đọc kỹ các nhận xét để lại ở một số phần nhất định. Và ngay cả khi chúng tôi đã nỗ lực hết sức, một số sai sót vẫn được xác định, một số sai sót đang được sửa chữa và cải thiện trong thời gian thực để mỗi người dùng tiếp theo nhận được dịch vụ tốt hơn.
Mỗi khóa học có chủ sở hữu sản phẩm riêng, người này ngoài việc xác định khái niệm chung, kiểm tra thời hạn, anh ta còn ghi chú bên lề rằng khi đến lúc phải viết lại hoàn toàn khóa học, và điều đó chắc chắn sẽ đến, bởi vì trong hai năm, hoặc thậm chí một năm sau, một số điều chúng ta kể sẽ trở nên không còn phù hợp chỉ vì nó đã trở nên lỗi thời về mặt đạo đức. Chủ sở hữu sản phẩm ghi chú bên lề mà hầu hết mọi người thường hỏi những điểm nào chưa rõ ràng, nhiệm vụ nào có vẻ rất khó và ngược lại, nhiệm vụ nào có vẻ rất đơn giản. Và tất cả điều này đều được tính đến khi ghi lại khóa học, trong một số kiểu tái cấu trúc, để mỗi lần lặp lại khóa học toàn cầu trở nên tốt hơn, thuận tiện và thoải mái hơn.
Đây là cách các khóa học xuất hiện.
Khóa học Docker ra đời như thế nào
Đây là một chủ đề riêng biệt và thậm chí bất thường đối với chúng tôi. Bởi vì một mặt, chúng tôi không có ý định làm điều đó vì nhiều trường trực tuyến cung cấp nó. Mặt khác, anh ấy đã yêu cầu được trả tự do và tìm thấy một vị trí hợp lý trong khái niệm đào tạo chuyên gia CNTT về Kubernetes của chúng tôi.
Nói một cách rất toàn cầu, ban đầu tất cả bắt đầu bằng một khóa học về Kubernetes, theo ý kiến của tôi, nó mới bắt đầu sau Slurm đầu tiên. Chúng tôi đã thu thập phản hồi và thấy rằng nhiều người muốn đọc thêm nội dung nào đó về Docker ở một nơi khác và nói chung, nhiều người đến với khóa học cơ bản về Kubernetes mà không biết nó là gì .
Do đó, đối với Slurm thứ hai, họ đã thực hiện một khóa học - hay đúng hơn, thậm chí không phải là một khóa học mà đã tạo một vài chương về Dockers. Nơi họ kể một số điều cơ bản nhất để những người đến với chuyên gia không cảm thấy thiếu thốn và nhìn chung sẽ hiểu chuyện gì đang xảy ra.
Và sau đó các sự kiện phát triển đại khái như thế này. Lượng vật liệu tăng lên và ngừng lắp sau 3 ngày. Và một ý tưởng hợp lý và rõ ràng đã xuất hiện: tại sao không biến những gì chúng tôi trình bày tại Slurm Basic thành một loại khóa học nhỏ nào đó mà bạn có thể gửi cho những người muốn xem nội dung nào đó về Docker trước khi tham gia một khóa học chuyên sâu về Kubernetes.
Trên thực tế, Slurm Junior là sự kết hợp của một số khóa học cơ bản như vậy. Kết quả là khóa học Docker đã trở thành một phần của Slurm Junior. Nghĩa là, đây là bước số XNUMX trước khi и . Và sau đó chỉ có những điều trừu tượng rất cơ bản.
Đến một lúc nào đó, mọi người bắt đầu hỏi: “Các bạn ơi, điều này thật tuyệt vời, điều này đủ để hiểu những gì các bạn đang nói ở các khóa học chuyên sâu. Tôi có thể đọc chi tiết hơn ở đâu về những gì docker có thể làm và cách làm việc với nó cũng như nó là gì?” Thế là nảy ra ý tưởng làm cho nó thẳng thắn , để trước hết, những người đến với Slurm bằng Kubernetes vẫn có thể được gửi đến nó, mặt khác, đối với những người thậm chí không quan tâm đến Kubernetes ở giai đoạn phát triển này. Để chuyên gia CNTT có thể đến xem khóa học của chúng tôi về Docker và bắt đầu con đường phát triển của mình một cách đơn giản với Docker thuần túy. Vì vậy, chúng tôi có một khóa học đầy đủ, đầy đủ như vậy - và sau đó nhiều người, sau khi xem khóa học này, đã làm việc một thời gian với Docker thuần túy, đã phát triển đến mức họ cần Kubernetes hoặc một số hệ thống điều phối khác. Và họ đặc biệt đến với chúng tôi.
Đôi khi câu hỏi được đặt ra: “Loại người nào bây giờ có thể không cần Kubernetes?” Nhưng câu hỏi này không phải về con người, mà là về các công ty. Ở đây bạn cần hiểu rằng Kubernetes có một số trường hợp nhất định rất phù hợp và các nhiệm vụ mà nó giải quyết tốt, nhưng ngược lại, có một số tình huống sử dụng Kubernetes khi nó gây thêm đau đớn và đau khổ thêm. Do đó, nó thậm chí không phụ thuộc vào con người mà phụ thuộc vào những gì công ty đã phát triển và trong bao lâu.
Ví dụ, một số khối Legacy khủng khiếp - có lẽ bạn không nên đẩy nó vào Kubernetes, vì nó sẽ gây ra nhiều vấn đề hơn là lợi ích. Hoặc, ví dụ, nếu đây là một dự án nhỏ, nó có tải trọng nhỏ hoặc về nguyên tắc, không có nhiều tiền và nguồn lực. Không có ích gì khi kéo nó vào Kubernetes.
Và nói chung, có lẽ, nói chung, như nhiều người đã nói, nếu bạn đặt câu hỏi: “Tôi có cần Kubernetes không?”, thì rất có thể bạn không cần nó. Theo tôi, tôi không nhớ ai là người đầu tiên nghĩ ra nó, Pasha Selivanov. Tôi đồng ý với điều này 100%. Và bạn cần phát triển Kubernetes - và khi mọi thứ trở nên rõ ràng rằng tôi cần Kubernetes và công ty chúng tôi cần nó, đồng thời nó sẽ giúp giải quyết các vấn đề tương tự, thì có lẽ bạn nên tìm hiểu và tìm ra chính xác cách thiết lập nó hoạt động tốt nên quá trình chuyển sang Kubernetes không gặp nhiều khó khăn.
Một số bệnh của trẻ em và một số điều đơn giản, thậm chí không đơn giản lắm, có thể được chúng tôi phát hiện ra cụ thể mà không phải trải qua sự cào xé và đau đớn của chính bạn.
Nhiều công ty đã đi theo con đường mà lúc đầu chỉ có một số loại cơ sở hạ tầng không có container. Sau đó, họ đến mức khó quản lý tất cả, họ chuyển sang Docker và đến một lúc nào đó, họ phát triển đến mức trở nên chật chội trong khuôn khổ Docker và những gì nó cung cấp. Và họ bắt đầu xem xét những gì xung quanh, hệ thống nào giải quyết những vấn đề này và đặc biệt là Kubernetes - đây là một trong những hệ thống cho phép bạn giải quyết các vấn đề khi Docker thuần túy trở nên đông đúc và thiếu chức năng, đây là một trường hợp thực sự tốt khi mọi người Họ đi từng bước từ dưới lên, hiểu rằng công nghệ này là chưa đủ và chuyển sang cấp độ tiếp theo. Họ đã sử dụng thứ gì đó, nó lại trở nên khan hiếm và họ tiếp tục.
Đây là một lựa chọn có ý thức - và nó rất tuyệt vời.
Nói chung tôi thấy hệ thống của chúng tôi được xây dựng rất đẹp, chẳng hạn như , thậm chí thông qua các khóa học video. Sau đó, sau docker nó đi , sau đó , sau đó . Mọi thứ đều sắp xếp hợp lý - một người vượt qua và một nghề vững chắc xuất hiện.
Về nguyên tắc, bộ khóa học cho phép bạn bao quát rất nhiều trường hợp, kể cả những trường hợp hiện đại. Vẫn còn những khu vực vẫn là vùng xám, tôi hy vọng rằng chúng tôi sẽ sớm tạo ra một số khóa học cho phép chúng tôi đóng những vùng xám này, đặc biệt, chúng tôi sẽ đưa ra điều gì đó về bảo mật. Bởi vì điều này đang trở nên rất phù hợp.
Nói tóm lại, chúng tôi có một số vùng màu xám mà sẽ rất tốt nếu đóng lại để nó trở thành một bức tranh hoàn chỉnh, hoàn chỉnh - và mọi người có thể đến, và giống như bản thân Kubernetes giống như một công cụ xây dựng Lego, bạn có thể tạo ra những thứ khác nhau từ nó thu thập, nếu vẫn chưa đủ - bổ sung, tương tự với các khóa học của chúng tôi, để mọi người có thể hiểu họ cần gì từ khóa học này; họ cần lắp ráp một loại câu đố, một loại công trình xây dựng từ các khóa học của chúng tôi.
Nếu bạn tự hỏi mình một câu hỏi nhìn chung chính xác và trung thực: “Ai có thể sử dụng khóa học Docker đang hoạt động bây giờ?”, Thì:
- Dành cho những sinh viên mới bắt đầu làm quen với nó.
- Nhân viên bộ phận kiểm nghiệm.
- Trên thực tế, có nhiều công ty không những không sử dụng Docker mà còn chưa có ai nghe nói đến công nghệ như vậy và về nguyên tắc là không biết cách sử dụng nó. Và tôi biết một số công ty lớn ở St. Petersburg đã phát triển trong nhiều năm và họ sử dụng một số công nghệ cũ, họ đang đi theo hướng này. Đặc biệt, đối với những công ty như vậy, đối với các kỹ sư ở những công ty như vậy, khóa học này có thể rất thú vị, vì thứ nhất, nó sẽ cho phép bạn nhanh chóng hòa mình vào công nghệ này và thứ hai, ngay sau khi một số kỹ sư xuất hiện, những người hiểu được tất cả. công việc, họ có thể mang nó đến công ty và phát triển văn hóa này cũng như những định hướng này trong công ty.
- Theo tôi, khóa học này có thể vẫn hữu ích với những người đã từng làm việc với docker, nhưng ngày càng có ít phong cách “làm một lần, làm hai lần” - và bây giờ họ sẽ tương tác bằng cách nào đó với cùng một Kubernetes, và điều này áp đặt những nghĩa vụ nhất định đối với họ, nếu bạn có kiến thức rất hời hợt về docker là gì, cách chạy nó, nhưng đồng thời bạn không biết nó hoạt động như thế nào từ bên trong, bạn không biết nên làm gì tốt nhất với nó và điều gì tốt hơn không nên làm, thì khóa học này rất phù hợp để hệ thống hóa và đào sâu kiến thức.
Nhưng nếu bạn có kiến thức ở mức độ: “Tôi không biết cách viết chính xác các tệp Docker giống nhau, tôi có thể hình dung không gian tên là gì, cách các vùng chứa hoạt động, cách chúng thực sự được triển khai ở cấp hệ điều hành” - thì đó là chắc chắn không có ích gì khi đến với chúng tôi, bạn sẽ không học được điều gì mới và bạn sẽ hơi buồn vì số tiền và thời gian đã bỏ ra.
Nếu chúng ta hình thành những lợi thế mà khóa học của chúng ta có, thì:
- Chúng tôi đã cố gắng thực hiện khóa học này với đủ số lượng trường hợp thực tế sẽ cho phép bạn không chỉ hiểu phần lý thuyết tồn tại mà còn hiểu lý do tại sao bạn cần nó và cách bạn sẽ sử dụng nó trong tương lai;
- có một số phần rất hiếm khi được tìm thấy ở bất cứ đâu - và nói chung không có nhiều tài liệu về chúng. Chúng liên quan đến sự tương tác của Docker với hệ điều hành, thậm chí có chút khác biệt. Docker đã lấy những cơ chế nào từ hệ điều hành để triển khai hệ thống container hóa - và điều này giúp hiểu sâu hơn về toàn bộ vấn đề chạy container trong hệ điều hành Linux. Nó hoạt động như thế nào, nó tương tác với nhau như thế nào bên trong hệ điều hành, bên ngoài, v.v.
Đây là một cái nhìn thực sự sâu sắc đến nỗi nó hiếm khi xảy ra, đồng thời, theo tôi, nó rất quan trọng. Nếu bạn muốn hiểu rõ về bất kỳ công nghệ nào và hiểu những gì mong đợi từ nó, ít nhất bạn cần có ý tưởng chung về cách thức hoạt động của nó ở mức độ thấp.
Khóa học của chúng tôi trình bày và cho biết cách hoạt động của tính năng này theo quan điểm của hệ điều hành. Một mặt, tất cả các hệ thống container hóa đều sử dụng các cơ chế hệ điều hành giống nhau. Mặt khác, họ lấy những gì có trong hệ điều hành Linux, như docker. Các hệ thống chứa khác không đưa ra bất kỳ điều gì mới - họ lấy những gì đã có trong Linux và chỉ viết một trình bao bọc tiện lợi cho phép bạn nhanh chóng gọi, chạy hoặc bằng cách nào đó tương tác với nó. Docker tương tự không phải là một lớp quá lớn giữa hệ điều hành và dòng lệnh, nó là một loại tiện ích cho phép bạn không phải viết hàng kiloton lệnh hoặc một số loại mã C để tạo vùng chứa mà để thực hiện điều này bằng cách nhập một vài dòng trong thiết bị đầu cuối.
Và một điều nữa, nếu chúng ta đang nói cụ thể về Docker, những gì Docker thực sự mang lại cho thế giới CNTT chính là các tiêu chuẩn. Ứng dụng nên được khởi chạy như thế nào, nó hoạt động như thế nào, các yêu cầu đối với nhật ký là gì, các yêu cầu về mở rộng quy mô, cấu hình ứng dụng là gì.
Theo nhiều cách, docker là về các tiêu chuẩn.
Các tiêu chuẩn cũng đang chuyển sang Kubernetes - và có những tiêu chuẩn giống hệt nhau; nếu bạn biết cách chạy tốt ứng dụng của mình trong Docker thì 99% trường hợp ứng dụng đó sẽ hoạt động tốt trong Kubernetes.
Nếu bạn thấy mình không chỉ quan tâm đến cách tạo khóa học Docker mà còn quan tâm đến các khóa học khác mà còn quan tâm đến chính khóa học đó từ quan điểm thực tế, thì
Chúng tôi sẽ rất vui được gặp bạn!
Nguồn: www.habr.com