Не хотите попробовать размещать свои уроки на платформе Stepic? Можно бесплатно и удобно создавать уроки с видео, текстовыми шагами и различными упражнениями (тестами с выбором правильного ответа из списка, задачами на программирование). Набор уроков можно объединить в мини-курс.
На CTFtime ничего не было, потому что их правила гласят о том, что CTFtime предназначен только для командных соревнований: CTFtime is for team competitions only! If your competition implies the participation of individuals we can't list it and post the scoreboard.
Еще интересно, как вы организуете версионирование образов контейнеров (названия, тэги)?
Правильно я понял, что ваша архитектура позволяет делать апдейты без даунтайма? Т.е. выкатываете новую версию контейнера, она уже входит в работу одновременно со старой, потом тушите старую. Балансировщики какие-то есть?
Да, хорошо мирантис написали. Типа пул публичных ip адресов. Если взять для примера amazon ec2, то там для инстенса выделяют 10.x.x.x адрес (приватный) и floating (публичный), по которому инстенс доступен из интернетов.
Не уверен, что это именно то, что нам будет нужно, может, приватные сетки для разных заданий лучше создавать. Хорошо бы еще по vlan'ам рассовать их разным. Вообще, были какие-то попытки сделать поддержку neutron (SDN controller) для докера в openstack'е, не в курсе, как там успехи.
В ближайшее время в конфигурации сети точно ничего не буду глобального менять.
Сервисы и все остальное (базы, message queue) тоже деплоим в контейнерах. Довольно сыро еще в этой области, вроде как docker совсем недавно начали активно это направление развивать blog.docker.com/tag/orchestration/.
Все хостовые системы у нас CentOS 7. Пока часть сервисов деплою с помощью Geard. Достаточно хорошо работает, особенно подходит для версий docker, когда в которых еще плохо работал механизм авторестарта контейнера (geard использует systemd). Еще geard'шные link'и мне понравились больше, чем встроенные в docker (geard разруливает линки с помощью iptables nat в сетевом неймспейсе контейнера).
Другую часть сервисов попробую деплоить уже без systemd, со встроенным авторестартом с помощью ansible. Не всем удовлетворил меня docker модуль для ansible. К примеру, нет возможность сделать docker pull нового имаджа с реестра. Можно передеплоить контейнер с предварительным pull'ом, но тогда получается даунтайм сервиса на время скачивания нового образа.
У нас тоже пока без особых изяществ и вкусностей насчет сети: все пользовательские контейнеры в одном L2 сегменте и одной 10.16.0.0/12 сети. Пока серьезных проблем с безопасностью не видится, возможно, позже допиливать будем nova-docker драйвер для поддержки floating network.
Да, вы все верно разобрали: в каждом контейнере помимо bash запускается еще sshd. Согласен, что есть оверхед с демоном ssh, запросто можно инспектировать контейнер и без него с docker-хоста. Но в этом случае нужно разрабатывать инструментарий, чтобы этим пользоваться. В случае с ssh, запустили демон и сразу имеем кучу тулов, которые с ним работают, в нашем случае библиотека fabric на python. В общем, иногда лучше добавить небольшой оверхед, чтобы снять с себя другие проблемы, эффективное решения которых не так и важно.
Интересно, а какой у вас опыт использования контейнеров?
В начале статье есть ссылка на первое задание из курса, можете сами посмотреть, запустить top, извините, htop не поставил :)). Да, пользователь видит все хостовые ресурсы, как есть, никак не справляемся с этим. Docker-хосты, кстати, — это KVM виртуалки. Сейчас задача стоит донести пользователям максимум нашего опыта, показать, как и что можно делать с платформой, собрать фидбек и двигать в правильном направлении. Можно, конечно, с головой закопаться в вопросах безопасности, стараемся находить некий компромисс.
1. Одна из причин — нежелание внедрять в проект еще одну нанотехнологию в лице node.js (docker'а с openstack'ом пока хватает более чем). Вторая причина — все равно ведь пришлось бы адаптировать штатный: нужен механизм аутентификации клиентского терминала, получение инфы о терминале от сервиса Mal, механизм подключения к tty контейнера (штатный, если я не ошибаюсь, поддерживает только tty сессию с локально запущенными процессами).
2. Миграция контейнеров не осуществляется. Пока нет родных средств миграции docker-контейнеров. Предполагаю, что можно извратиться и мигрировать контейнер с помощью CRIU, т.к. по сути контейнер — это обычный процесс, запущенный в необычном окружении. А вообще оно и не критично сейчас: ну издох сервер, ну упали текущие решаемые задания, да, грусть и печаль, но не смертельно.
3. На диаграмме показано, что Zoe общается по ssh с docker-контейнерами, не хостами. Эта связь нужна для выполнения удаленных команд в контейнере. На данный момент ssh оказался самым простым и доступным способом проверки состояния контейнера, в частности файловой системы. Если с контейнерами еще можно играться через хостовую систему, то с полноценной виртуалкой сложно что-то похожее сделать с гипервизора. Для виртуалок, видимо, ssh тоже будет самым простым способом пошариться во внутренностях машинки.
Не пробовали, и вряд ли это имеет для нас смысл. OpenStack выбран с перспективой, что вскоре добавим поддержку полноценных виртуалок, например, на KVM. Могут быть нужны для создания более сложных упражнений, которые выходят за рамки возможностей контейнеров. Например, задания по настройке сети, туннелей, каким-нибудь махинациям с ядром.
В таком случае мы добавим новые compute-ноды с гипервизором KVM в наше облако и автоматом по тому же OpenStack API сможем запускать и контейнеры, и нормальные виртуалки.
На CTFtime ничего не было, потому что их правила гласят о том, что CTFtime предназначен только для командных соревнований: CTFtime is for team competitions only! If your competition implies the participation of individuals we can't list it and post the scoreboard.
Еще интересно, как вы организуете версионирование образов контейнеров (названия, тэги)?
Правильно я понял, что ваша архитектура позволяет делать апдейты без даунтайма? Т.е. выкатываете новую версию контейнера, она уже входит в работу одновременно со старой, потом тушите старую. Балансировщики какие-то есть?
Не уверен, что это именно то, что нам будет нужно, может, приватные сетки для разных заданий лучше создавать. Хорошо бы еще по vlan'ам рассовать их разным. Вообще, были какие-то попытки сделать поддержку neutron (SDN controller) для докера в openstack'е, не в курсе, как там успехи.
В ближайшее время в конфигурации сети точно ничего не буду глобального менять.
Все хостовые системы у нас CentOS 7. Пока часть сервисов деплою с помощью Geard. Достаточно хорошо работает, особенно подходит для версий docker, когда в которых еще плохо работал механизм авторестарта контейнера (geard использует systemd). Еще geard'шные link'и мне понравились больше, чем встроенные в docker (geard разруливает линки с помощью iptables nat в сетевом неймспейсе контейнера).
Другую часть сервисов попробую деплоить уже без systemd, со встроенным авторестартом с помощью ansible. Не всем удовлетворил меня docker модуль для ansible. К примеру, нет возможность сделать docker pull нового имаджа с реестра. Можно передеплоить контейнер с предварительным pull'ом, но тогда получается даунтайм сервиса на время скачивания нового образа.
Интересно, а какой у вас опыт использования контейнеров?
2. Миграция контейнеров не осуществляется. Пока нет родных средств миграции docker-контейнеров. Предполагаю, что можно извратиться и мигрировать контейнер с помощью CRIU, т.к. по сути контейнер — это обычный процесс, запущенный в необычном окружении. А вообще оно и не критично сейчас: ну издох сервер, ну упали текущие решаемые задания, да, грусть и печаль, но не смертельно.
3. На диаграмме показано, что Zoe общается по ssh с docker-контейнерами, не хостами. Эта связь нужна для выполнения удаленных команд в контейнере. На данный момент ssh оказался самым простым и доступным способом проверки состояния контейнера, в частности файловой системы. Если с контейнерами еще можно играться через хостовую систему, то с полноценной виртуалкой сложно что-то похожее сделать с гипервизора. Для виртуалок, видимо, ssh тоже будет самым простым способом пошариться во внутренностях машинки.
В таком случае мы добавим новые compute-ноды с гипервизором KVM в наше облако и автоматом по тому же OpenStack API сможем запускать и контейнеры, и нормальные виртуалки.