есть смысл кореос и докера? или сразу rkt?

на CoreOS можно и Docker и Rkt, CoreOS - облачная система, если у вас 3+ сервера, то это хороший выбор, на 1 сервере я бы не советовал

для обновлений там нужны ребуты, что в случае 1 сервера неудобно

Rkt достаточно стабилен, версия 1.0 вышла в феврале, кажется... но всё же сообщество пока не очень большое, я использую в продакшене (начал неделю-две назад), у меня сайтики в контейнерах, работают стабильно, сегодня обновился на новую версию Rkt, тоже всё нормально прошло...

Rkt не заставляет вас отказываться от всего того, что вы достигли с докером - попробуйте запустить через него парочку контейнеров на сервере и посмотреть, если всё нормально - переведёте потом остальные

если у вас одиночный сервер, я бы вам посоветовал Ubuntu 16.04 LTS + Rkt (+ Docker для подстраховки, если боитесь за Rkt),

https://coreos.com/docs/sdk-distributors/sdk/modifying-coreos/ первая ссылка

посмотрел, но всё равно не понял как-то...

вот я нашёл конфиг ядра https://github.com/coreos/coreos-overlay/tree/master/sys-kernel/coreos-modules/files

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

но для начала, хотелось бы просто научиться делать CoreOS с монолитным ядром (ну, допустим, я параноик и боюсь руткитов)

и да я согласен с тем что докер слишком много жрет.

и пока не может реально прожевать

нормальную очерёдность запуска контейнеров на ранчере не сделать, поэтому для облаков выбора особо и нет - CoreOS лучшая ОС для этой цели

а сам Rkt имеет много приятных фич

например, можно отделить запуск пода от его подготовки

то есть сначала скачиваем образы и готовим под и только потом рестартим все поды на новые

таким образом, простой во время обновления снижается буквально до нескольких секунд

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

докер же не умеет так

докер силён со стороны клиента/программиста

интеграция с IDE, нормальные версии под macOS и Windows

а со стороны сервера - если заменить его на Rkt, потом жалеть не будешь

Good morning ☕️

Frederic Branczyk из CoreOS рассказал как мониторить etcd с помощью Prometheus. Значительная часть статьи, в которой рассказывается о ключевых метриках etcd, пригодится и для других систем мониторинга. http://amp.gs/8LQR

А на машину с coreos както glusterfs можно поставить? Не в контейнер а на сам хост

А на машину с coreos както glusterfs можно поставить? Не в контейнер а на сам хост

Вопрос зачем? Этот гластер не нужен :( найдите другое решение

о, а другое - это какое например?

Ceph ))

ожидаемый ответ)

надо сходить, посмотреть

а если у меня небольшая среда для внутренних сервисов, coreos и мэнэджить я всё это хочу просто флитом, то на чем сторадж сделать? простого nfs хватит?

мне чисто вольюмы монтировать с конфигами/сырцами

ну вообще у кореоса есть свой ответ сефам и гластерам

https://github.com/coreos/torus

интересно

нужно больше дистрибутед файловых систем.

а еще больше тестовых пользователй готовых потерять данные

господа, я правильно понимаю, что использовать токен с discovery.etcd.io для сетапа кореос кластера - это не очень даже для дев окружения и мне сначала нужно etcd установить у себя в окружении, а потом уже кластер сетапить?

о, а другое - это какое например?

Из много. Lizardfs, moosefs, cephfs, glusterfs, это не считая других более исторических кластерных фс

я положительные отзывы только о ceph слышал, ну вот glusterfs ещё. посмотрю остальные, спасибо

https://github.com/coreos/torus

было бы интересно услышать отзывы о нём

ну пока все так и будут ждать отзывов, появиться им будет неоткуда

ну, я один из первых, кто начал использовать rkt в продакшене (правда мои проекты начального уровня и никаких потерь [кроме моих репутационных] в случае оффлайна на полчаса-час не будет), так что я не отсиживаюсь в сторонке) а вот что касается сетевой фс - то особой потребности в ней нет (не важно, в какой именно), наверное, я подожду опыта тех, кому она реально нужна...

если уж буду потом ставить - наверное, отдам предпочтение решению от CoreOS, чтобы был единый стэк

как я понимаю, сейчас лидеры - это Ceph и Swift, первую стоит использовать в рамках 1 датацентра, вторую - если хочется сделать фс на основе серверов в разных датацентрах, статья в блоге мирантиса описывает и сравнивает кратко эти сетевые фс https://www.mirantis.com/blog/object-storage-openstack-cloud-swift-ceph/

Это не сетевая файловая система, а object storage

Я про статью, что ты привёл

Расскажите про сетап кореос в вашей девелоперской среде, пожалуйста. У вас стоит etcd внутри на отдельном сервере? Мне по сути пока нужно только токен выдать и кластер собирать от этого etcd. И я правильно понимаю, что etcd, запущенные на кореос будут объединяться в кластер без etcd, который токен выдавал для кластера?

Я про статью, что ты привёл

да, спасибо, я это и имел в виду) [подойдёт для отправки туда статики на хранение, с API как у AWS]

ну только важно понимать, чем это отличается от blob storage

Расскажите про сетап кореос в вашей девелоперской среде, пожалуйста. У вас стоит etcd внутри на отдельном сервере? Мне по сути пока нужно только токен выдать и кластер собирать от этого etcd. И я правильно понимаю, что etcd, запущенные на кореос будут объединяться в кластер без etcd, который токен выдавал для кластера?

я сейчас из этого стэка только Rkt использую на Ubuntu, когда куплю третий сервер - буду пробовать ставить CoreOS, но надеюсь, вам подскажут... вообще, для разработки это работает с помощью Vagrant'а, а на сервере - там 2 метода, кажется - cloud init и ignition

https://github.com/coreos/ignition/blob/master/doc/getting-started.md

для разработки поднять локально - это всё понятно. У меня есть локальные сервисы около 10-12 штук (инвентаризация, сенсу, разные морды для сетапа хостов и тому подобное), сейчас всё разбросано фиг пойми где, сетапится как попало. Я хочу запихать всё это в контейнеры и засунуть в кореос

и сделать доку, чтобы не возникало вопросов, где, как запустить новый сервис

ну и утилизовать ресурсы по максимуму

а то есть вмваре виртуалки, где работает 2 крона и 1 nginx, в который ходят раз в год (скедулер вмваре конечно должен и сам не выдавать ресурсов им, но диск как минимум не оверселится)

у меня сейчас это сделано так: есть балансировщик за пределами облака, он страхует от потери одного из провайдеров или серверов, всё крутится в контейнерах Rkt, правда вот пока на Ubuntu...

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

самое простое - без облака через systemd их запускать, ступенька выше - Fleet на CoreOS

ещё выше - Kubernetes

kubernetes - уже слишком, хотя в некоторых случаях могло бы и пригодиться

ну вот для моих целей пока самый простой вариант балансировщик + контейнеры подходит, через некоторое время я всё-таки освою CoreOS, но мне там кое-чего не хватает, поэтому, наверное, мне сначала захочется разобраться, как делать свою сборку CoreOS (доустановить туда некоторые пакеты)

а чего не хватает?

питончика

ещё есть утилиты для мониторинга некоторые

ещё ядро бы немного по-другому собрать

ещё шифрование разделов диска

чтобы при запуске пароль спрашивал

и еще бы mdraid с lvm ;)

там Btrfs была одно время

потом они её убрали зачем-то

чтобы при запуске пароль спрашивал

ты тем саммым эффективно превратишь кореось в обычную. ибо сломаешь онлайн обновление

как раз тогда, когда она глючить перестала

ты тем саммым эффективно превратишь кореось в обычную. ибо сломаешь онлайн обновление

тут должен быть свой апдейт-сервер, который получает новую версию, доустанавливает туда нужные пакеты и раздаёт нодам кластера

он сам может работать как виртуалка или контейнер

если при запуск ебудет спрашиваться пароль - всё. нода обновилась и не поднялась.

какой прок в шифровании ?

ну, если конфискуют)

такое чувство, будто ты дисклесс бут по PXE хочешь прикрутить)

ну да, можно и так стартовать