Linux docker kubernetes

Kubernetes: знакомство, часть 1 — архитектура и основные компоненты, обзор

На текущем проекте у нас имеется API-бекенд для мобильных приложений на PHP Yii-фреймворке, который работает на стандартном LEMP — Linux/NGINX/PHP-FPM/MySQL.

Пришла пора и нам разбивать этот монолит на микросервисы, для управления которыми будет использоваться Kubernetes ( AWS EKS ).

В этом и последующих постах серии — знакомство с основными компонентами и архитектурой Kubernetes, ручное создание кластера и работа с AWS EKS.

Ниже достаточно кратко рассматривается общая архитектура, основные компоненты и понятия Kubernetes, а в следующих — перейдём к более практическим примерам, понемногу углубляюсь в детали и расширяя кругозор экосистемы Kubernetes.

В посте добавлено достаточно много ссылок до материалы, но основная проблема при поиске документации/примеров по Kubernetes — это то, что изменения появляются часто и быстро, а потому любые примеры и документация быстро устаревают — имейте это ввиду.

Архитектура — обзор

Общая схема K8s кластера выглядит так:

Или более простая схема:

Кластер состоит из одной или более Master Node, и одной или более Worker Node.

Master Node

Сервисы, работающие на Master-ноде называются « Kubernetes Control Plane » (кроме etcd ), при этом сам Master используется только для административных задач, тогда как реальные контейнеры с вашими сервисами будут запущены на Worker Node.

Kubernetes core services aka Kubernetes Control Plane

На Master Node работают три основных компонента, которые обеспечивают работу всех компонентов системы:

kube-apiserver
- основная точка входа для всех запросов — например, любые команды от kubectl отправляются в виде API-запросов к kube-apiserver на Master Node
- API-сервер обрабатывает все REST-запросы, валидирует их и обновляет информацию в etcd (API-сервер единственный, кто работает с etcd — все остальные компоненты кластера выполняют запросы к API-серверу, а он уже обновляет информацию в etcd , см. Взаимодействие компонтентов)
- выполняет аутентификацию и авторизацию клиентов
kube-scheduler
- определяет, на какой Worker Node создавать новый pod (см. Pod), в зависимости от требуемых ресурсов и занятости нод
kube-controller-manager
- демон, включающий в себя Controllers , такие как Replication Controller, Endpoints Controller и Namespace Controller
- проверяет состояние кластера через API-сервер, и выполняет необходимые изменения
- занимается созданием и обслуживаем Linux Namespaces и garbage collection

Key:value хранилище, используемое Kubernetes для управления конфигурациями и service discovery .

Кроме того, в нём хранится текущее (current) состояние системы, и желаемое (desired), например — после деплоймента.

Если K8s находит отличия в etcd между состояниями current и desired — он выполняет необходимые изменения.

Worker Node

Worker Node (ранее — minion) — виртуальная или физическая машина, на которой имеются компоненты Kubernetes для запуска Pod (см. Pod).

На Worker Node-ах работают два компонента:

kubelet : основной компонент Kubernetes на каждой ноде кластера — проверяет API-сервер на предмет появления описания новых Pods, которые должны быть развёрнуты на данной ноде
- обращается с Docker (или другой системой контейнеризации, например rkt или containerd ) через их API для управления контейнерами
- после внесения изменений в состояние пода на ноде — передаёт информацию о статусе обратно к API-серверу (который, в свою очередь, вносит их в etcd )
- мониторит состояние контейнеров
kube-proxy : аналог реверс-прокси сервера, отвечает за пересылку и проксирование запросов к соответствующим сервисам или приложениям в приватной сети Kubernetes-кластера
- по умолчанию использует IPTABLES (просмотреть правила можно с помощью kubectl -n kube-system exec -ti kube-proxy-5ctt2 — iptables —table nat —list )
- см. Understanding Kubernetes Kube-Proxy

Взаимодействие компонтентов

Например, при создании нового pod-а — процесс выглядит так:

kubectl шлёт запрос к API-серверу
API-сервер валидирует его, и передаёт в etcd
etcd сообщает обратно API-серверу, что запрос принят и сохранён
API-сервер обращается к kube-scheduler
kube-scheduler определяет ноду(ы), на которой будет создан pod, и возвращает информацию обратно API-серверу
API-сервер отправляет эти данные в etcd
etcd сообщает обратно API-серверу, что запрос принят и сохранён
API-сервер обращается к kubelet на соответствующей ноде(ам)
kubelet обращается к Docker демону (или другому container runtime ) через его API через сокет Docker-демона на ноде с задачей запустить контейнер
kubelet отправляет статус pod-а API-серверу
API-сервер обновляет данные в etcd

Абстракции Kubernetes

Выше мы говорили о более-менее «осязаемых» вещах, таких как виртуальные машины, сети, IP-адреса и прочее.

Но сам Kubernetes являет собой один большой кусок… абстракции, «накладываемой» на виртуальную или физическую инфрастуктуру.

Соответственно, в K8s имеется множество собственных объектов, являющихся абстрактными, или логическими, компонентами Kubernetes.

Pod — основная логическая единица Kubernetes.

По сути своей, под является такой себе абстракцией виртуальной машины внутри Kunbernetes-кластера: у него есть свой приватный IP, имя хоста, общие данные на дисках (см. Volumes).

Pod является юнитом деплоймента (см. Deployment), и «внутри» этой «машины» запускаются один или более контейнеров, связанных общим назначением, и представляющих собой логическое приложение (состоящее из одного или более процессов/контейнеров).

Каждый под предзначен для запуска и обслуживания единственного экземпляра приложения: если вы хотите выполнить горизонтальное масштабирование приложения — вы должны использовать различные поды, по одному на каждый инстанс приложения.

Такая группа нод (Replicated Pods) управляется контроллером (см. Controllers).

При этом сами контейнеры не являются объектами Kubernetes и не управляются им: Kubernetes управляет подами, но контейнеры внутри этого пода используют общее сетевое пространство имён, включая IP адреса и порты, и могут обращаться друг к другу через localhost (потому как под == логическая виртуальная машина).

Пример шаблона для создания пода может выглядеть так:

Services

Сервисы — это, в первую очередь, про сеть внутри кластера и обеспечение доступа к подам из мира — они позволяют выполнять коммуникацию между различными компонентами внутри и снаружи приложения.

По сути, сервисы — точно такие же объекты Kubernetes, как Pod, ReplicaSets, DaemonSet, при этом вы можете представлять себе сервис как ещё один виртуальный сервер в ноде.

Например, сервисы можно условно обозначить так:

Тут пользователь приходит к приложению через один сервис, и попадает на фронтенд, затем сам фронтенд через два других сервиса взаимодействует с двумя сервисами бекенда, которые, в свою очередь, через ещё один сервис — общаются с серверов баз данных.

ClusterIP

Открывает доступ к сервису через внутренний IP кластера. Таким образом — сервис будет доступен только внутри самого класетра.

Является типом по-умолчанию.

NodePort

Этот тип открывает доступ к приложению, используя статический IP рабочей ноды кластера. Автоматически создаёт ClusterIP для приложения, на который будет роутиться трафик с NodePort .

30008 — внешний порт на ноде, на который можно подключаться к сервису ( NodePort ), должен быть в диапазоне 30000 — 32767
NodePort сервис — с ClusterIP и собственным портом (Port) и IP из блока serviceSubnet
Pod с приложением в нём — под принимает подключения на порт 80 (TargetPort) и имеет IP из блока podSubnet

Увидеть подсети можно с помощью kubeadm config view :

Kubernetes: разбираемся с системой управления контейнерами

Содержание статьи

С появлением Docker интерес к контейнерам вырос взрывообразно: разворачивать приложения оказалось настолько удобно, что технологию начали использовать буквально везде. Облачные сервисы уже дают быстрый доступ к большому количеству виртуальных машин, которыми нужно управлять. Поэтому без инструмента, позволяющего запускать контейнеры на множестве хостов, масштабировать и выполнять балансировку, уже не обойтись. Разберемся с решением, предложенным Google.

Проект Kubernetes

Проект Kubernetes, или K8S, стартовал в Google в 2014 году, первая публичная версия 0.1 была представлена сообществу практически через год — в июле 2015-го. Нужно, наверное, особо отметить, что разработка не начиналась с нуля. В основе K8S лежит суперсекретный (в буквальном смысле этого слова) проект Гугла Borg — фактически основа основ управления кластерами в этой корпорации, проект, наработками которого до этого гигант не особо хотел делиться. Многие из разработчиков Borg перешли в Kubernetes, а вместе с ними туда перекочевали все идеи и решения проблем — перенос контейнеров без потерь данных, балансировка нагрузки, обнаружение сервисов. То есть можно сказать, что K8S — точная копия того, что в Google создавали долгое время, но адаптированная и ориентированная к применению Docker. Сразу после анонса проекта совместно с Linux Foundation была сформирована Cloud Computing Native Foundation (CNCF), в которую вошли сама Google, Cisco, IBM, Docker и VMware. Задача CNCF — выработать единый стандарт и обеспечить взаимодействие между разработчиками.

В Kubernetes реализованы все функции, необходимые для запуска приложений на основе Docker в конфигурации с высокой доступностью (кластеры более 1000 узлов, с multi-availability и multi-region зонами): управление кластером, планирование, обнаружение сервисов, мониторинг, управление учетными данными и многое другое. Выглядит это пугающе, но вся внутренняя кухня скрыта от админа. Он просто размещает контейнеры, все остальное — забота K8S. Для реализации этого используется больше десятка сторонних взаимодействующих услуг, которые вместе обеспечивают требуемую функциональность. Например, за координацию и хранение настроек отвечает etcd, создание сетей между контейнерами — flannel. Это несколько усложняет первоначальную настройку (хотя в последних релизах это уже не так заметно), но позволяет при необходимости просто заменить любой компонент. Для состыковки служб используются разные CLI, API, которые уже совместно реализуют API более высокого уровня для сервисных функций, таких как планирование ресурсов. Нужная функциональность должна быть специально адаптирована для K8S. Например, обратиться напрямую к API Docker нельзя (точнее, можно, но очень и очень нежелательно), следует использовать Docker Compose.

Читать еще: Приложение для оптимизации

Kubernetes представляет собой систему с несколькими концепциями. Многие из этих понятий проявляются как «объекты» или «ресурсы» RESTful API. Кроме общепринятых, таких как Node, Cluster и Replication controller, есть и весьма специфические.

Pods — единица планирования в Kubernetes. Группа или ресурс, в котором могут работать несколько контейнеров. Контейнеры из одного Pod будут запускаться на одном сервере и могут совместно использовать общие разделы. Объекты Pod описаны в так называемых PodSpec — YAML/JSON-файлах.
Services — набор контейнеров, которые работают вместе, обеспечивая, например, функционирование многоуровневого приложения. K8S поддерживает динамическое наименование и балансировку нагрузки Pods с помощью абстракций, гарантируя прозрачное подключение к Services по имени и отслеживая их текущее состояние.
Labels — пары ключ/значение, которые прикрепляются к Pod и фактически к любому объекту (сервису), позволяя их легко группировать, отбирать и назначать задания.
IP-per-Pod — в Borg сервисы использовали один IP и для распределения сетевых ресурсов применялись порты. Это накладывало ряд ограничений. В K8S возможно назначить каждому Pod отдельный адрес.
Namespaces — способ, позволяющий логически разделить единый кластер K8S на несколько виртуальных, каждый из них будет существовать в изолированном пространстве, ограниченном квотами, не влияя на других.

На всех узлах кластера minion устанавливаются агенты kubelet и kube-proxy (прокси-балансировщик). Агенты принимают из специального API сервера данные PodSpec (файл или HTTP) и гарантируют работоспособность указанных в нем объектов. Прокси обеспечивает перенаправление потоков между Pod. Мастер кластера содержит специальные компоненты — kube-controller-manager (менеджер сервисов) и kube-scheduler (планировщик), kube-apiserver, etcd и flannel. Доступ к API управления, кроме программного способа, можно получить через консольную утилиту kubectl и веб-интерфейс. С их помощью можно просматривать текущую конфигурацию, управлять ресурсами, создавать и разворачивать контейнеры.

Установка Kubernetes

Установка Kubernetes выполняется скриптом, и в процессе следует ориентироваться на официальную инструкцию, адаптировав ее к своему дистрибутиву. Она несложная, просто нужно быть очень внимательным. Мануалы из Сети работают не всегда, так как в разных версиях дистрибутива часто требуются различные действия и встречаются специфические проблемы, также разработчики по мере развития K8S меняют процесс развертывания и параметры в конфигурационных файлах. Установим в простейшем варианте K8S на одну систему master/minion в Ubuntu 14.04/16.04, так что нам не потребуются некоторые компоненты вроде сервера ключей. Перед установкой нужно составить список всех узлов и их сетевые параметры и роль. Проект предлагает исходные тексты и bash-скрипт.

Скрипт установки Kubernetes

Первый вариант дает чуть больше контроля, если что-то пойдет не так. Ставим приложения:

Для беспарольного входа генерируем ключ. Так как впоследствии понадобятся права root, то ключи генерируем для него. Все параметры оставляем по умолчанию, на запрос пароля жмем Enter.

Подтверждаем операцию и вводим свой пароль.

После этого пробуем войти. Должно пустить без запроса пароля:

Если серверов несколько, поступаем аналогично и копируем на них ключи. Несмотря на простоту, это очень важный момент. Малейшая ошибка — и дальнейшие действия ни к чему не приведут. Забираем актуальный релиз (файл большой, почти 1,5 Гбайт):

Или ветку master:

Архив содержит примеры и готовые настройки в kubernetes/cluster для самых разных конфигураций. Следует выбрать свою и запустить установочный скрипт. Так как ставим на Ubuntu, то выбираем этот вариант. Для начала нам нужно указать конфигурацию сети. Смотрим вывод ifconfig — настройку физического интерфейса и docker0 — и приступаем к настройке.

Конфигурационный файл config-default.sh

Это основные настройки, позволяющие запустить K8S. В файле также настраиваются параметры Docker и остальных компонентов, журналирование, мониторинг. Если к интернету подключение происходит через прокси, то его параметры следует прописать в PROXY_SETTING .

Теперь можно развернуть кластер.

Скрипт закачает и установит все необходимые компоненты (etcd), на все прописанные в конфиге ноды. В процессе потребуется указать пароль для управления узлом. По окончании получим сообщение Cluster validation succeeded. Причем скрипт повторно будет скачивать последний релиз K8S — чтобы не повторять это дважды, просто скопируй файл kubernetes.tar.gz в каталог kubernetes/cluster/ubuntu и подправь скрипт закачки download-release.sh .

Еще одна проблема, которую не могут устранить уже пару месяцев, — это ошибка при создании кластера:

Нужный файл расположен в каталоге kubernetes/server , его просто забыли положить на место. Это можно сделать вручную или добавить в cluster/ubuntu/download-release.sh две строки распаковки kubernetes-salt .

После чего master будет слушать на порту http://127.0.0.1:8080. Остановить кластер можно также одной командой:

Устанавливаем Kubernetes

Управляем кластером

Для управления K8S используется утилита kubectl. Настройки можно указывать прямо в командной строке или использовать заранее подготовленный YAML/JSON-файл. Чтобы было проще вводить команды, укажем в переменной PATH, где ее искать.

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее

Kubernetes — установка, что такое и для чего нужен

Сегодня открываю новый цикл статей, которые будут иметь непосредственное отношение к Devops и всему, что с этим связано. Начну с того, что расскажу, как установить и запустить кластер Kubernetes на собственном железе. Буду использовать установку через Kubespray с использованием ingress контроллера в кластере.

Цели статьи

Коротко рассказать о том, что такое Kubernetes и для чего он нужен.
Перечислить основные системные требования для разворачивания своего кластера Kubernetes.
Выполнить непосредственно установку кластера на свое железо.

Введение

Хочу сразу обратить внимание на важный момент. У меня нет опыта промышленной эксплуатации кластера Kubernetes. Я нахожусь в состоянии обучения и исследования этого инструмента. Я прошел обучение Слёрм, это дало базовые знания и понимание принципов работы. Дальше стал разворачивать свои кластера и исследовать их. Изначально я не хотел писать статьи по этой теме до тех пор, пока не накопится достаточного опыта, но сейчас поменял свое мнение.

В рунете очень мало материалов по kubernetes с конкретикой и практикой, по которым можно было бы учиться. Думаю, что даже те знания, что есть сейчас у меня, будут многим полезны и интересны. Плюс, когда пишешь статьи, систематизируешь свои знания, запоминаешь и получаешь обратную связь. Ускоряется процесс обучения. Так что статьям по kubernetes и devops в целом быть. Думаю, что в ближайшее время я сфокусируюсь именно на этом.

Могу однозначно сказать, что если у вас есть необходимость в продакшене использовать Kubernetes, не тяните время и не откладывайте. Идите учиться на курсы. Самостоятельно вы не освоите в достаточном объеме материал, чтобы можно было переносить рабочую нагрузку в свой кластер. Очень много нюансов и подводных камней. Вы потратите больше времени, нервов и денег на самостоятельное освоение, если будете сами все с нуля изучать.

Лично у меня сейчас нет цели становиться администратором Kubernetes. Мой формат занятости не подразумевает обслуживание таких крупных систем и в планах этого тоже пока нет. Мне просто любопытно его исследовать, узнавать что-то новое, поэтому я этим занимаюсь. Знания карман не тянут, особенно современные и востребованные.

Kubernetes простыми словами

Попробую рассказать своими словами, что такое кластер Kubernetes для чайников, без отсылок к описаниям и документации. По своей сути это кластер для обслуживания docker контейнеров. Я слышал, что он может управлять не только докером, но практически ничего про это не знаю. Все в основном используют Kubernetes в связке с Docker.

Читать еще: Оптимизация пинга в онлайн играх

В Kubernetes все крутится вокруг докер контейнеров. Это инструмент для их запуска, поднятия в случае падения, распределения ресурсов и т.д. Под капотом никакой магии. Там обычный docker, iptables, etcd, nat, dns, ceph, nfs и т.д. Просто все собрано в одном месте для решения конкретных задач. Таким образом, для эффективного управления кластером кубера нужен хороший бэкграунд классического linux админа. Без этих знаний будет трудно.

Есть много способов разворачивания кластера, так как он модульный. Не всем и не всегда нужны все его компоненты. К примеру, есть ingress контроллер для распределения входящих запросов по сервисам. Под капотом там обычный nginx в режиме proxy_pass, интегрированный в инфраструктуру кластера. Реализация сети в кластере тоже может быть разной — на уровне l2 или l3 с помощью тех или иных технологий. То же самое с файловыми хранилищами — локальные хранилища серверов, nfs хранилища, ceph и т.д.

В зависимости от того, какой функционал вам нужен, выбирается способ установки кластера kubernetes. Мы можете его установить полностью вручную, добавляя один компонент за другим. А можно использовать готовое средство, к примеру Kubespray, где весь необходимый для установки функционал реализуется с помощью ролей ansible. На Слёрме нас учили ставить кластер, используя свой форк компании southbridge. Они там немного изменили функционал под свои потребности. Я ставил и по их форку, и по оригинальному Kubespray. Основное отличие от классического Kubespray в том, что не используется kubeadm и сертификаты для общения компонентов кластера сразу выпускаются то ли на 10, то ли на 100 лет, не помню точно. В Kubespray сертификаты выписываются только на год и надо отдельно следить за их актуальности и своевременно обновлять.

Подведу итог о том, что же такое Kubernetes. Кубернетис — средство оркестрации (управления) контейнерами Docker. Это удобный инструмент для их автоматического запуска, выделения ресурсов, контроля состояния, обновления.

Кому нужен Kubernetes

Теперь порассуждаем о том, кому может пригодиться Kubernetes. В первую очередь это крупные компании со своими разработками в ИТ и командами программистов, для которых нужна большая производственная среда. Кластер Кубера добавляет серьезные накладные расходы на свое содержание, поэтому в небольших проектах выгоды от него не будет. Нет смысла объединить 5 маленьких виртуалок в кластер и эксплуатировать его. Если только для тестов. Или если вы точно уверены, что у проекта будет серьезный рост в ближайшее время. Под небольшую структуру и нагрузки лучше подыскать решения попроще, чем кубернетис.

Kubernetes накладывает серьезные требования к приложениям, которые в нем работают. Они должны быть изначально спроектированы и написаны по принципу микросервисов. У вас не получится взять и перенести в кластер сайт на wordpress или bitrix, даже если они очень большие и нагруженные. Вернее, перенести то вы их сможете, но вряд ли вам от этого будет проще и удобнее. Основное преимущество кластера — гибкость в разработке, деплое приложения, а так же в распределении ресурсов.

Примерная схема работы с кластером кубернетис на пальцах будет такая:

Разработчики какого-то одного сервиса проекта выпускают обновление, запушив его в репозиторий.
Система сборки формирует докер контейнер с этими изменениями и кладет в registry.
Контейнер уезжает на тесты и если все в порядке, выкатывается в продакшн кластер kubernetes.

Это я очень просто и условно описал. Все процессы после пуша кода в репозиторий могут быть автоматизированы. Команд разработчиков, как и микросервисов, может быть десятки. Они могут условно независимо друг от друга выкатывать обновления. У каждого сервиса могут быть свои языки программирования, свои системные требования, свои файловые хранилища и базы данных. Все эти сущности отдельно описываются в конфигурациях кластера. Каждый микросервис получает то, что ему нужно для работы.

Теперь смотрим на Bitrix или WordPress. Они являются монолитными приложениями, написанными на php с использованием базы Mysql. В них нет микросервисов. Вам нужно либо как-то разбивать их на части, либо постоянно выкатывать все целиком. Но в этом случае смысл кластера кубернетис теряется, его гибкость настроек и выделения ресурсов под потребности не используются. Вам проще поставить обычный балансер на вход, сделать несколько нод для обработки php и за ними кластер БД.

Резюмируя все сказанное. Kubernetes — нишевое решение под конкретные проекты. Оно подходит далеко не всем и не надо его пихать туда, где от него не будет толку. Думаю, находятся люди, которые так делают. Сужу по тому, что мне в комментариях к некоторым статьям, например, про установку zabbix, пишут, а почему вы не в докере его ставите. Люди не понимают, что такое докер, для чего он нужен и какие проблемы решает. Смысла в использовании zabbix в docker нет никакого вообще. Docker создан для удобной разработки и деплоя приложений в продакшн. Этакий расширенный пакетный менеджер. В первую очередь он инструмент разработчиков.

Системные требования

Как таковых жестких системных требований у Kubernetes нет. Он с очень маленьких установок расширяется до огромных кластеров. Для того, чтобы его просто попробовать и посмотреть, достаточно следующих виртуальных машин:

2-3 мастер ноды с 2 cpu и 4 gb ram
ingress нода с 1 cpu и 2 gb ram
рабочие ноды для контейнеров от 2 cpu и 4 gb ram

Для того, чтобы просто запустить кластер, достаточно буквально двух виртуальных машин, которые одновременно будут и мастер и рабочими нодами. Но я рекомендую сразу планировать более ли менее полную структуру, которую можно брать за основу для последующего превращения в рабочий кластер. Я буду разворачивать кластер на следующих виртуальных машинах.

Kubernetes — установка, что такое и для чего нужен

Цели статьи

Коротко рассказать о том, что такое Kubernetes и для чего он нужен.
Перечислить основные системные требования для разворачивания своего кластера Kubernetes.
Выполнить непосредственно установку кластера на свое железо.

Введение

Kubernetes простыми словами

Читать еще: Как оптимизировать слабый ноутбук под игры

Кому нужен Kubernetes

Примерная схема работы с кластером кубернетис на пальцах будет такая:

Разработчики какого-то одного сервиса проекта выпускают обновление, запушив его в репозиторий.
Система сборки формирует докер контейнер с этими изменениями и кладет в registry.
Контейнер уезжает на тесты и если все в порядке, выкатывается в продакшн кластер kubernetes.

Системные требования

2-3 мастер ноды с 2 cpu и 4 gb ram
ingress нода с 1 cpu и 2 gb ram
рабочие ноды для контейнеров от 2 cpu и 4 gb ram

Docker и Kubernetes: Полное руководство

Docker and Kubernetes: The Complete Guide

Создавайте, тестируйте и развертывайте приложения Docker с Kubernetes во время обучения рабочим процессам реальной продакшн разработке. Если вы устали изучать как развернуть веб-приложения, этот курс для вас. CI + CD Workflows? Вы узнаете это. Развертывание AWS? В комплекте. Kubernetes в продакшене? Конечно! Это полное руководство, как развернуть любое веб-приложение, которое вы можете придумать. Docker и Kubernetes являются новейшей технологией в мире Dev Ops и резко изменили поток создания и развертывания веб-приложений. Docker — это технология, позволяющая приложениям запускаться в конструкциях, называемых «контейнерами», а Kubernetes позволяет запускать множество разных «контейнеров».

Докер с нуля!

В этом курсе вы узнаете Докер из абсолютных основ, начиная с изучения ответа на основные вопросы, такие как «Что такое контейнер?» и «Как работает контейнер?». С самых первых лекций мы сделаем глубокое погружение во внутренние работы контейнеров, чтобы вы поняли, как именно они реализованы. Как только вы поймете, что такое контейнер, вы научитесь работать с ними, используя основные команды Docker CLI. После этого вы будете применять свое новое мастерство в Docker CLI для создания собственных пользовательских имейжов, эффективно «Подгружая» ваши собственные личные приложения.

CI + CD Pipelines

Конечно, ни один курс на Docker не был бы полным без полного понимания общих моделей непрерывной интеграции и непрерывного развертывания. Вы узнаете, как реализовать полный рабочий процесс CI + CD с помощью Github, Travis CI и Amazon Web Services, создавая конвейер, который автоматически развертывает ваш код каждый раз, когда вы вносите свои последние изменения в Github!

Развертывание много контейнеров на AWS!

После создания конвейера развертывания вы примените его для освоения как одноконтейнерных, так и многоконтейнерных развертываний в Amazon Web Services. Вы создадите многоконтейнерное приложение, использующее Node, React, Redis и Postgres, и увидите потрясающую способность контейнеров в действии (Примечание: Javascript в этом курсе является необязательным, полный исходный код предоставляется, если вы не хотите писать JS).

Kubernetes!

Наконец, вы будете работать с Kubernetes, система для управления сложными приложениями с множеством различных контейнеров. Вы узнаете, как правильно построить кластер Kubernetes — этот курс не имеет ни одного из этих раздражающих комментариев «не делайте этого в продакшене»! Сначала вы создадите кластер Kubernetes на своей локальной машине, а затем переместите его на облачного провайдера. Вы даже узнаете, как настроить HTTPS на Kubernetes, что сложнее, чем кажется!

Вот что вы будете делать:

Изучите Docker с нуля
Создадите свои собственные изображения, адаптированные к вашим приложениям
Усвоите командную строку Docker для проверки и отладки запущенных контейнеров
Поймете, как Docker работает за кулисами, и что такое контейнер
Сделаете конвейер CI + CD с нуля с помощью Github, Travis CI и AWS
Автоматически развернете свой код при его появлении в Github!
Создадите сложное многоконтейнерное приложение с нуля и развернете его в AWS
Поймете цель и теорию Кубернетов
Развернете готовый к производству кластер Kubernetes в облаке Google