Позвольте поделиться с вами новым стеком, состоящим из кластера Kubernetes и набора специализированных расширений, которые позволят вам реализовывать ежедневные сложные рабочие процессы. Конечно, простое развёртывание Kubernetes и его расширений само по себе не приносит большой пользы. Если у вашей команды нет навыков разработки или развёртывания в Kubernetes, не говоря уже о понимании интеграции и использования сторонних расширений с вашими приложениями, тогда какая от этого польза для вас, верно?
Я руководил командами, разрабатывающими приложения, предназначенные для работы в Kubernetes. С годами стало очевидно, что, несмотря на величие платформы, в комнате был слон… Давайте заглянём немного глубже в эту кроличью нору, окей?
Создавать образы контейнеров и запускать их, например, с помощью docker‑compose, достаточно просто. Большинство разработчиков знают, как добраться туда без особых хлопот. Но если вы хотите серьёзно подойти к запуску своих приложений в продакшен средах, у вас практически не будет другого выбора, кроме как проявить интерес к такой платформе, как Kubernetes.
Kubernetes — это совершенно другой зверь. Простое подключение тома с некоторыми предварительно заполненными данными, предоставление порта для обеспечения доступности вашего приложения или просто обдумывание того, как все сочетается, приобретают совершенно иной смысл, когда вам приходится делать это в Kubernetes. Для тех из вас, у кого была возможность работать c k8s помимо простого варианта использования «hello world» и у кого нет докторской степени в Kubernetes, вероятно, хорошо известно, что я имею в виду под этим. Но сложность выходит далеко за рамки этих нескольких примеров.
Запуск приложения в продакшн — непростая задача. В Kubernetes есть механизмы, позволяющие решать самые сложные аспекты продакшн сред (автоматическое масштабирование, сетевая безопасность, поддержка кластеров, бесконечная расширяемость). Также они создают огромную сложность, которая часто мешает разработчикам и DevOps‑инженерам эффективно использовать их. Большинство разработчиков говорят, что знают Kubernetes, когда я спрашиваю их об этом. Они считают, что если они один раз задеплоили pod и прикрепили к нему том, у них есть базовое понимание, которого достаточно для работы с кластером. Давайте добавим ещё несколько модных словечек и посмотрим, вызовут ли они у вас знакомые нервные импульсы:
Что касается HELM, это отличный менеджер пакетов для рабочих нагрузок kubernetes. Но создание собственных HELM charts — сложная задача. У каждого приложения есть выделенный chart, обычно он настраивается специально для этого приложения, однако оно развертывает аналогично структурированные ресурсы Kubernetes под капотом. Вследствие этого придётся детально изучить каждый файл HELM chart»а «values.yaml», чтобы понять, как его использовать. Почему?
«PersistetVolumes» и «PersistedVolumeClaims» позволяют вам сохранять данные вашего приложения, даже когда ваше приложение выходит из строя.
Эти тома и файлы скрыты где‑то в кластере вне вашей досягаемости, и каждый новый том, созданный для вашего приложения, сначала полностью пуст. Видите, к чему я клоню с этим? Итак, что, если у меня есть какие‑то данные, которые я хотел бы поместить в том, от которого зависит мое приложение? Экс‑исходная схема базы данных и набор данных, статический веб‑сайт, который служит базой для моего приложения и т. д. Давайте посмотрим правде в глаза, пустой том — это хорошо, но иногда ему нужны некоторые предварительно заполненные данные. Обычно вам приходится усложнять приложение всевозможными механизмами инициализации, которые обнаруживают пустой том и заполняют его, прежде чем вы действительно сможете начать его использовать.
Я мог бы продолжить с такими темами, как Ingress и Gateway, SSO, ACL, управление сертификатами и так далее, но я думаю, вы поняли суть.
Это то, что я вижу каждый день, когда разработчик присоединяется к нашей команде и обнаруживает готовый к продакшену Kubernetes, который он должен понимать, чтобы разрабатывать и тестировать приложения. Количество времени, которое я трачу на изучение всех этих концепций, огромно, не говоря уже о количестве времени, которое разработчики должны тратить на исследования и изучение. Когда разработчик увольняется, ему должны найти замену и начать обучать заново. В конечном итоге это обходится компании очень дорого. Так почему же Kubernetes настолько сложен в использовании? Следующее утверждение довольно хорошо подводит итог этому:
Kubernetes сложен, поэтому ваши приложения не должны быть такими!
Если бы вы могли использовать Kubernetes и все его зависимости, но без необходимости беспокоиться о понимании и освоении всего этого… Что ж, может быть, вы и сможете!
Итак, что же представляет собой платформа MDos?
MDos — это неуправляемый вариант Kubernetes. Он развёртывает для вас кластер K3S Kubernetes и несколько выбранных инструментов и расширений вокруг него, чтобы сделать его полностью готовым к развёртыванию Kubernetes в рабочей среде. Вдобавок ко всему, он добавляет уровень управления, позволяющий связать все это воедино так, чтобы вы могли сосредоточиться на использовании доступных функций платформы, а не внедрять и настраивать эти функции самостоятельно. Он также предоставляет платформу для объединения ваших приложений в развертываемый ресурс, который позволяет вам подключать к вашим приложениям дополнительные функции: SSO, управление сертификатами TLS, вход, управление журналами и др.
После установки на сервер у вас будут запущены следующие компоненты, готовые к работе:
Чтобы установить платформу MDos, обратитесь к документации, доступной здесь: https://mdundek.github.io/mdos/installation.
Чтобы установить MDos CLI, обратитесь к документации, доступной здесь: https://mdundek.github.io/mdos/installation/#install-the-mdos-cli .
CLI также используется для создания каркаса приложений MDos. Он предоставляет стандартизированную структуру папок, которая используется для хранения исходного кода приложения, файлов конфигурации и зависимостей, которые затем можно развернуть в кластере.
Приложения следует рассматривать как концепцию более высокого уровня. Приложение mDos состоит из одного или нескольких компонентов приложения. Компоненты приложения — фактические заполнители ресурсов вашего проекта (исходный код), где один компонент может быть, например, внутренним сервером API, а второй компонент будет содержать ваше интерфейсное приложение.
К каждому компоненту приложения может быть присоединен один или несколько томов для обеспечения сохраняемости хранилища и зеркального отображения данных. Эта архитектура позволяет создавать сложные приложения в соответствии с вашими потребностями.
Макет проекта приложения MDos состоит из одной или нескольких папок, каждая из которых представляет компонент приложения.
В корне папки приложения находится файл «mdos.yaml», который содержит все параметры конфигурации среды выполнения для приложения и его компонентов:
my-application/
├── backend
│ └── Dockerfile
│ └── <your application code files>...
├── frontend
│ └── Dockerfile
│ └── <your application code files>...
├── volumes
│ └── static-website
│ └── index.html
│ └── ...
└── mdos.yaml
В этом примере у нас есть приложение с именем my‑application, которое состоит из двух различных компонентов приложения: backend и frontend. Каждый компонент имеет свой собственный Dockerfile.
На уровне приложения также существует папка volumes, в которой вы можете хранить файлы томов компонентов приложения, которые будут использоваться в вашем приложении, и конфигурационный файл mdos.yaml, содержащий все параметры конфигурации среды выполнения. В качестве примера, здесь в папке volumes есть подпапка под названием static‑website, которая используется интерфейсным приложением для обслуживания данных своего веб‑сайта.
Если вы хотите развернуть его самостоятельно, воспользуйтесь официальной страницей «Начало работы«, упомянутой выше, для получения более подробных инструкций о том, как его воспроизвести.
Допустим, вы хотите разработать новое приложение, которое должно быть развернуто на Kubernetes. Для этого используйте Dos CLI:
mdos generate application
? Enter a application name: hello-world
? Enter a tenant name that this application belongs to: a-team
Это создаст новую папку с конфигурационным файлом mdos.yaml в нем. Теперь можно переходить к созданию компонентов приложения. Внутри папки проекта вашего приложения выполните следующую команду:
cd hello-world
mdos generate component
? Enter a application component name: hello-world-server
CLI задаст вам пару вопросов о параметрах базовой конфигурации. Это создаст новую папку компонента с Dockerfile, а также обновит файл mdos.yaml, ссылающийся на компонент как на часть общего проекта приложения вместе с его параметрами конфигурации.
Теперь вы можете приступить к реализации компонента приложения hello‑world‑server. Создадим базовый HTTP‑сервер NodeJS, который при вызове будет возвращать «hello world».
Создайте новый файл: hello‑world/hello‑world‑server/index.js
const http = require('http');
http.createServer((request, response) => {
response.writeHead(200, {
'Content-Type': 'text/plain'
});
response.write('Hello, World!\n');
response.end();
}).listen(8080);
И последнее, но не менее важное: нужно заполнить Dockerfile нашего компонента,, чтобы мы могли создавать образ контейнера во время развертывания. Откройте Dockerfile, который находится внутри папки hello-world-server, и установите его содержимое:
FROM node:16
# Create app directory
WORKDIR /usr/src/app
# Bundle app source
COPY ./server.js .
EXPOSE 8080
CMD [ "node", "server.js" ]
Теперь у нас есть приложение, готовое к использованию. Далее нужно сообщить приложению mdos, что мы хотим открыть порт 8080, и настроить входящую конфигурацию, чтобы предоставить его за пределами кластера, используя имя хоста hello‑world.mydomain.com.
Начнем с предоставления доступа к порту 8080 для компонента приложения. Это можно сделать с помощью сервиса kubernetes. Перейдите в папку компонента hello‑world‑server и выполните команду:
mdos generate service
? Enter a name for the service to add a port to: http
? Specify a port number on which your application needs to be accessible on: 8080
И, наконец, вход, чтобы у нас было имя хоста, настроенное для доступа к этому приложению:
mdos generate ingress
? Enter a name for the ingress: http-ingress
? What hostname do you want to use to access your component port: hello-world.mydomain.com
? Do you want to match a subpath for this host? No
? What target port should this traffic be redirected to? 8080
? What type of traffic will this ingress handle? http
Вот как теперь должна выглядеть файловая структура проекта:
hello-world
├── hello-world-server
│ ├── Dockerfile
│ └── server.js
├── mdos.yaml
└── volumes
└── README.md
Давайте взглянем на сгенерированный код в файле mdos.yaml:
schemaVersion: v1
tenantName: a-team
appName: hello-world
uuid: mvx10-x2wip
components:
- name: hello-world-server
image: hello-world
uuid: qx8su-jwqvi
tag: 0.0.1
services:
- name: http
ports:
- port: 8080
ingress:
- name: http-ingress
matchHost: hello-world.mydomain.com
targetPort: 8080
trafficType: http
Все функции настройки приложения будут находиться внутри этого файла yaml, даже для самых продвинутых вариантов использования и конфигурационных потребностей — все будет здесь. Не нужно пачкаться с низкоуровневыми абстракциями kubernetes, платформа переведет все в необходимые вам артефакты.
Чтобы узнать больше обо всем, что вы можете настроить для своих развертываний в этом файле yaml, пожалуйста, ознакомьтесь со справочной документацией по приложению Msdos.
Прежде чем приступить к развертыванию нового приложения, нужно создать пространство имён, в котором мы сможем развернуть это приложение.
В Kubernetes пространства имен используются для группировки ресурсов, чтобы их можно было правильно администрировать и запускать в их собственном контексте с ограниченной областью действия.
В MDos мы назначаем выделенное пространство имен каждому клиенту на платформе. Приложения принадлежат к пространству имен клиентов, без этого пространства имен мы не сможем развернуть приложение.
Чтобы создать новое пространство имен клиента с именем a-team, выполните следующую команду:
mdos namespace create
? Enter a namespace name to create: a-team
Creating namespace... done
Не создавайте свои пространства имен с помощью kubectl CLI. Это позволит обойти несколько шагов настройки, необходимых для использования всех расширенных функций MDos.
Теперь развернем наш пример «Hello World» в кластере. Перейдите в приложение hello-world и выполните команду:
mdos application deploy
Synching volumes... done
To push your images to the mdos registry, you need to provide your mdos username and password first
? Username: admin-username
? Password: ********
Building application image registry.mydomain.com/a-team/hello-world:0.0.1... done
Pushing application image registry.mydomain.com/a-team/hello-world:0.0.1... done
Deploying application... scheduled
Pod: hello-world-server
Phase: Running
Container: hello-world-hello-world-server
State: running
Details: n/a
SUCCESS : Application deployed
Вот и все, теперь ваше приложение должно быть доступно в следующем домене: https://hello-world.mydomain.com
Поскольку это базовый пример, мы пока пропускаем такие темы, как управление пользователями, аутентификация или любые другие расширенные темы. Поскольку мы прошли аутентификацию с помощью учетной записи администратора MDos, мы можем выполнять развертывание в этом пространстве имен без создания или назначения пользователей и разрешений для этого пространства имен.
Вот несколько полезных ссылок с более подробной информацией и расширенными вариантами использования:
Репозиторий GitHub находится здесь:
Установите платформу: https://mdundek.github.io/mdos/installation/
Начало работы: https://mdundek.github.io/mdos/getting-started/
Справочный документ для “mdos.yaml”: https://mdundek.github.io/mdos/reference-documentation/
Расширенные темы: https://mdundek.github.io/mdos/advanced-resources/
habr.com
Слон в комнате
Я работаю с Kubernetes уже несколько лет, это потрясающая платформа, универсальная, расширяемая и мощная. Но с большой силой приходит большая ответственность!Я руководил командами, разрабатывающими приложения, предназначенные для работы в Kubernetes. С годами стало очевидно, что, несмотря на величие платформы, в комнате был слон… Давайте заглянём немного глубже в эту кроличью нору, окей?
Создавать образы контейнеров и запускать их, например, с помощью docker‑compose, достаточно просто. Большинство разработчиков знают, как добраться туда без особых хлопот. Но если вы хотите серьёзно подойти к запуску своих приложений в продакшен средах, у вас практически не будет другого выбора, кроме как проявить интерес к такой платформе, как Kubernetes.
Kubernetes — это совершенно другой зверь. Простое подключение тома с некоторыми предварительно заполненными данными, предоставление порта для обеспечения доступности вашего приложения или просто обдумывание того, как все сочетается, приобретают совершенно иной смысл, когда вам приходится делать это в Kubernetes. Для тех из вас, у кого была возможность работать c k8s помимо простого варианта использования «hello world» и у кого нет докторской степени в Kubernetes, вероятно, хорошо известно, что я имею в виду под этим. Но сложность выходит далеко за рамки этих нескольких примеров.
Запуск приложения в продакшн — непростая задача. В Kubernetes есть механизмы, позволяющие решать самые сложные аспекты продакшн сред (автоматическое масштабирование, сетевая безопасность, поддержка кластеров, бесконечная расширяемость). Также они создают огромную сложность, которая часто мешает разработчикам и DevOps‑инженерам эффективно использовать их. Большинство разработчиков говорят, что знают Kubernetes, когда я спрашиваю их об этом. Они считают, что если они один раз задеплоили pod и прикрепили к нему том, у них есть базовое понимание, которого достаточно для работы с кластером. Давайте добавим ещё несколько модных словечек и посмотрим, вызовут ли они у вас знакомые нервные импульсы:
- Управление доступом на основе ролей (не многие люди используют его, оно интуитивно непонятное и слишком сложное, в результате чего все становятся «root»)
- Сетевые политики (ограничение сетевого трафика между приложениями, требуется совместимый CNI, сложный в использовании)
- Хранилища данных (Ceph, NFS, Longhorn, пути к хостам...)
- Типы хранилища (ReadWriteOnce, ReadWriteMany...)
- Много ресурсов на выбор: Pods, Deployments, StatefulSets, DaemonSets, Services,VirtualServices, Gateways, Ingress, PVs, PVCs, Secrets, ConfigMaps, Roles, ClusterRoles, RoleMappings.
- Отладка приложений в Kubernetes (журналы, состояние, ресурсы...)
Что касается HELM, это отличный менеджер пакетов для рабочих нагрузок kubernetes. Но создание собственных HELM charts — сложная задача. У каждого приложения есть выделенный chart, обычно он настраивается специально для этого приложения, однако оно развертывает аналогично структурированные ресурсы Kubernetes под капотом. Вследствие этого придётся детально изучить каждый файл HELM chart»а «values.yaml», чтобы понять, как его использовать. Почему?
«PersistetVolumes» и «PersistedVolumeClaims» позволяют вам сохранять данные вашего приложения, даже когда ваше приложение выходит из строя.
Эти тома и файлы скрыты где‑то в кластере вне вашей досягаемости, и каждый новый том, созданный для вашего приложения, сначала полностью пуст. Видите, к чему я клоню с этим? Итак, что, если у меня есть какие‑то данные, которые я хотел бы поместить в том, от которого зависит мое приложение? Экс‑исходная схема базы данных и набор данных, статический веб‑сайт, который служит базой для моего приложения и т. д. Давайте посмотрим правде в глаза, пустой том — это хорошо, но иногда ему нужны некоторые предварительно заполненные данные. Обычно вам приходится усложнять приложение всевозможными механизмами инициализации, которые обнаруживают пустой том и заполняют его, прежде чем вы действительно сможете начать его использовать.
Я мог бы продолжить с такими темами, как Ingress и Gateway, SSO, ACL, управление сертификатами и так далее, но я думаю, вы поняли суть.
Это то, что я вижу каждый день, когда разработчик присоединяется к нашей команде и обнаруживает готовый к продакшену Kubernetes, который он должен понимать, чтобы разрабатывать и тестировать приложения. Количество времени, которое я трачу на изучение всех этих концепций, огромно, не говоря уже о количестве времени, которое разработчики должны тратить на исследования и изучение. Когда разработчик увольняется, ему должны найти замену и начать обучать заново. В конечном итоге это обходится компании очень дорого. Так почему же Kubernetes настолько сложен в использовании? Следующее утверждение довольно хорошо подводит итог этому:
Kubernetes сложен, поэтому ваши приложения не должны быть такими!
Если бы вы могли использовать Kubernetes и все его зависимости, но без необходимости беспокоиться о понимании и освоении всего этого… Что ж, может быть, вы и сможете!
MDos спешат на помощь
У меня такое ощущение, что это проблемное пространство вокруг Kubernetes ещё не было должным образом рассмотрено. Существуют коммерческие решения, которые имеют большое значение (но только в определенной степени), например, «OpenShift». С открытым исходным кодом в этом отношении их не так много, за исключением большого количества документации.Итак, что же представляет собой платформа MDos?
MDos — это неуправляемый вариант Kubernetes. Он развёртывает для вас кластер K3S Kubernetes и несколько выбранных инструментов и расширений вокруг него, чтобы сделать его полностью готовым к развёртыванию Kubernetes в рабочей среде. Вдобавок ко всему, он добавляет уровень управления, позволяющий связать все это воедино так, чтобы вы могли сосредоточиться на использовании доступных функций платформы, а не внедрять и настраивать эти функции самостоятельно. Он также предоставляет платформу для объединения ваших приложений в развертываемый ресурс, который позволяет вам подключать к вашим приложениям дополнительные функции: SSO, управление сертификатами TLS, вход, управление журналами и др.
После установки на сервер у вас будут запущены следующие компоненты, готовые к работе:
- узел Kubernetes
- Istio (возможности входа и сетки);
- Cert‑Manager (управление сертификатами TLS);
- OAuth2-прокси (аутентификация SSO / OAuth2 / OIDC);
- Longhorn (распределенное блочное хранилище для Kubernetes);
- Loki & Grafana (агрегатор логов и панель мониторинга);
- Registry Docker (ваш собственный частный и безопасный реестр образов);
- Keycloak (гибкое управление аутентификацией);
- FTP‑сервер (позволяет синхронизировать объёмные данные с модулями);
- MDos Controller / API (делает для вас объемный список, чтобы интегрировать и скрыть сложность для всех вышеперечисленных инструментов)
Чтобы установить платформу MDos, обратитесь к документации, доступной здесь: https://mdundek.github.io/mdos/installation.
Интерфейс MDos CLI
Этот интерфейс командной строки устанавливается на каждом компьютере, с которого вам необходимо взаимодействовать с платформой. Это ваш швейцарский армейский нож, который позволит вам внедрять и настраивать сложные задачи рабочего процесса вокруг Kubernetes и его зависимостей.
Чтобы установить MDos CLI, обратитесь к документации, доступной здесь: https://mdundek.github.io/mdos/installation/#install-the-mdos-cli .
CLI также используется для создания каркаса приложений MDos. Он предоставляет стандартизированную структуру папок, которая используется для хранения исходного кода приложения, файлов конфигурации и зависимостей, которые затем можно развернуть в кластере.
Анатомия в проекте MDos
Приложения следует рассматривать как концепцию более высокого уровня. Приложение mDos состоит из одного или нескольких компонентов приложения. Компоненты приложения — фактические заполнители ресурсов вашего проекта (исходный код), где один компонент может быть, например, внутренним сервером API, а второй компонент будет содержать ваше интерфейсное приложение.
К каждому компоненту приложения может быть присоединен один или несколько томов для обеспечения сохраняемости хранилища и зеркального отображения данных. Эта архитектура позволяет создавать сложные приложения в соответствии с вашими потребностями.
Макет проекта приложения MDos состоит из одной или нескольких папок, каждая из которых представляет компонент приложения.
В корне папки приложения находится файл «mdos.yaml», который содержит все параметры конфигурации среды выполнения для приложения и его компонентов:
my-application/
├── backend
│ └── Dockerfile
│ └── <your application code files>...
├── frontend
│ └── Dockerfile
│ └── <your application code files>...
├── volumes
│ └── static-website
│ └── index.html
│ └── ...
└── mdos.yaml
В этом примере у нас есть приложение с именем my‑application, которое состоит из двух различных компонентов приложения: backend и frontend. Каждый компонент имеет свой собственный Dockerfile.
На уровне приложения также существует папка volumes, в которой вы можете хранить файлы томов компонентов приложения, которые будут использоваться в вашем приложении, и конфигурационный файл mdos.yaml, содержащий все параметры конфигурации среды выполнения. В качестве примера, здесь в папке volumes есть подпапка под названием static‑website, которая используется интерфейсным приложением для обслуживания данных своего веб‑сайта.
Создание и развертывание простого приложения “Hello world”
Этот пример подробно описан в разделе Начало работы на сайте документации MDos. Мы повторно используем этот пример здесь в целях иллюстрации.Если вы хотите развернуть его самостоятельно, воспользуйтесь официальной страницей «Начало работы«, упомянутой выше, для получения более подробных инструкций о том, как его воспроизвести.
Допустим, вы хотите разработать новое приложение, которое должно быть развернуто на Kubernetes. Для этого используйте Dos CLI:
mdos generate application
? Enter a application name: hello-world
? Enter a tenant name that this application belongs to: a-team
Это создаст новую папку с конфигурационным файлом mdos.yaml в нем. Теперь можно переходить к созданию компонентов приложения. Внутри папки проекта вашего приложения выполните следующую команду:
cd hello-world
mdos generate component
? Enter a application component name: hello-world-server
CLI задаст вам пару вопросов о параметрах базовой конфигурации. Это создаст новую папку компонента с Dockerfile, а также обновит файл mdos.yaml, ссылающийся на компонент как на часть общего проекта приложения вместе с его параметрами конфигурации.
Теперь вы можете приступить к реализации компонента приложения hello‑world‑server. Создадим базовый HTTP‑сервер NodeJS, который при вызове будет возвращать «hello world».
Создайте новый файл: hello‑world/hello‑world‑server/index.js
const http = require('http');
http.createServer((request, response) => {
response.writeHead(200, {
'Content-Type': 'text/plain'
});
response.write('Hello, World!\n');
response.end();
}).listen(8080);
И последнее, но не менее важное: нужно заполнить Dockerfile нашего компонента,, чтобы мы могли создавать образ контейнера во время развертывания. Откройте Dockerfile, который находится внутри папки hello-world-server, и установите его содержимое:
FROM node:16
# Create app directory
WORKDIR /usr/src/app
# Bundle app source
COPY ./server.js .
EXPOSE 8080
CMD [ "node", "server.js" ]
Теперь у нас есть приложение, готовое к использованию. Далее нужно сообщить приложению mdos, что мы хотим открыть порт 8080, и настроить входящую конфигурацию, чтобы предоставить его за пределами кластера, используя имя хоста hello‑world.mydomain.com.
Начнем с предоставления доступа к порту 8080 для компонента приложения. Это можно сделать с помощью сервиса kubernetes. Перейдите в папку компонента hello‑world‑server и выполните команду:
mdos generate service
? Enter a name for the service to add a port to: http
? Specify a port number on which your application needs to be accessible on: 8080
И, наконец, вход, чтобы у нас было имя хоста, настроенное для доступа к этому приложению:
mdos generate ingress
? Enter a name for the ingress: http-ingress
? What hostname do you want to use to access your component port: hello-world.mydomain.com
? Do you want to match a subpath for this host? No
? What target port should this traffic be redirected to? 8080
? What type of traffic will this ingress handle? http
Вот как теперь должна выглядеть файловая структура проекта:
hello-world
├── hello-world-server
│ ├── Dockerfile
│ └── server.js
├── mdos.yaml
└── volumes
└── README.md
Давайте взглянем на сгенерированный код в файле mdos.yaml:
schemaVersion: v1
tenantName: a-team
appName: hello-world
uuid: mvx10-x2wip
components:
- name: hello-world-server
image: hello-world
uuid: qx8su-jwqvi
tag: 0.0.1
services:
- name: http
ports:
- port: 8080
ingress:
- name: http-ingress
matchHost: hello-world.mydomain.com
targetPort: 8080
trafficType: http
Все функции настройки приложения будут находиться внутри этого файла yaml, даже для самых продвинутых вариантов использования и конфигурационных потребностей — все будет здесь. Не нужно пачкаться с низкоуровневыми абстракциями kubernetes, платформа переведет все в необходимые вам артефакты.
Чтобы узнать больше обо всем, что вы можете настроить для своих развертываний в этом файле yaml, пожалуйста, ознакомьтесь со справочной документацией по приложению Msdos.
Прежде чем приступить к развертыванию нового приложения, нужно создать пространство имён, в котором мы сможем развернуть это приложение.
В Kubernetes пространства имен используются для группировки ресурсов, чтобы их можно было правильно администрировать и запускать в их собственном контексте с ограниченной областью действия.
В MDos мы назначаем выделенное пространство имен каждому клиенту на платформе. Приложения принадлежат к пространству имен клиентов, без этого пространства имен мы не сможем развернуть приложение.
Чтобы создать новое пространство имен клиента с именем a-team, выполните следующую команду:
mdos namespace create
? Enter a namespace name to create: a-team
Creating namespace... done
Не создавайте свои пространства имен с помощью kubectl CLI. Это позволит обойти несколько шагов настройки, необходимых для использования всех расширенных функций MDos.
Теперь развернем наш пример «Hello World» в кластере. Перейдите в приложение hello-world и выполните команду:
mdos application deploy
Synching volumes... done
To push your images to the mdos registry, you need to provide your mdos username and password first
? Username: admin-username
? Password: ********
Building application image registry.mydomain.com/a-team/hello-world:0.0.1... done
Pushing application image registry.mydomain.com/a-team/hello-world:0.0.1... done
Deploying application... scheduled
Pod: hello-world-server
Phase: Running
Container: hello-world-hello-world-server
State: running
Details: n/a
SUCCESS : Application deployed
Вот и все, теперь ваше приложение должно быть доступно в следующем домене: https://hello-world.mydomain.com
Поскольку это базовый пример, мы пока пропускаем такие темы, как управление пользователями, аутентификация или любые другие расширенные темы. Поскольку мы прошли аутентификацию с помощью учетной записи администратора MDos, мы можем выполнять развертывание в этом пространстве имен без создания или назначения пользователей и разрешений для этого пространства имен.
Вот несколько полезных ссылок с более подробной информацией и расширенными вариантами использования:
Репозиторий GitHub находится здесь:
Установите платформу: https://mdundek.github.io/mdos/installation/
Начало работы: https://mdundek.github.io/mdos/getting-started/
Справочный документ для “mdos.yaml”: https://mdundek.github.io/mdos/reference-documentation/
Расширенные темы: https://mdundek.github.io/mdos/advanced-resources/
MDos — Стек Kubernetes с открытым исходным кодом
Позвольте поделиться с вами новым стеком, состоящим из кластера Kubernetes и набора специализированных расширений, которые позволят вам реализовывать ежедневные сложные рабочие процессы....
habr.com