Раз уж это машина целиком

И это нечеловечески долго

Как оно, кстати, есть опыт использования (rkt) ?

нет, я жду версию 1.8

А образ LXC собирать? Да ну его нахер

Лучше докер сразу

Проблема LXC в том, что в LXC внутрь мы доставляем энсиблом

Это можно делать на билд сервере

Нет - ну, можно packer + lxc

Сколько человек в мире делают packer + lxc?

Это можно делать на билд сервере

Можно из буханки и катушки ниток сделать троллейбус

Но зачем?

Сначла объясните зачем мне в инфраструктуре 100 контейнеров

Можно из буханки и катушки ниток сделать троллейбус

Докер - по сути и есть такой троллейбус.

Когда все можно упаковать в 15 штук

Докер - по сути и есть такой троллейбус.

Нет, докер, по сути, это декларативный интерфейс к императивным вещам

С понятными conventions

И довольно удачным

Нет, докер, по сути, это декларативный интерфейс к императивным вещам

Ну с точки зрения того что у него под капотом - это дикий бутерброд

Они могли бы быть поудачнее, но для старта и так норм

Ну с точки зрения того что у него под капотом - это дикий бутерброд

В императивном мире Unix-систем иначе не получается

А то давно бы додумались

Впрочем, есть же Nixpkgs

Но, опять же, сколько человек в мире про это знают

UNIX как раз подразумевает одна тулза = одна задача

UNIX как раз подразумевает одна тулза = одна задача

И этот принцип не работает за пределами своих граничных условий (сюрприз!)

А граничные условия у него наступают на каждом шагу

Все эти ваши микросервисы возможны только в проектах, где можно пожертвовать локальностью данных

Сначала скажи что в этом хорошего

мы разделяем 1 большую систему на много мелких - это хорошо, проще найти ошибку

А где нельзя - добро пожаловать в kernel space

https://www.ansible.com/press/ansible-2.1?utm_campaign=ansible%202.1&utm_content=32938244&utm_medium=social&utm_source=twitter

Все эти ваши микросервисы возможны только в проектах, где можно пожертвовать локальностью данных

Стоп, так докер же как раз для микросервисов удобнее всего. Разве нет?

Стоп, так докер же как раз для микросервисов удобнее всего. Разве нет?

Если уж говорить за микросервисы, удобнее всего для них Golang

Который статическим бинарником распространяется

Правда, там с вендорингом пока какая-то жопа

Но это починят

мы разделяем 1 большую систему на много мелких - это хорошо, проще найти ошибку

Кто сказал что в моей системе сложно найти ошибку? Я же объяснил что апп сервер у меня атомарен. Не работает - выкинуть из апстрим нахер значит

Я про то, что база отдельно, фронтенд отдельно, бекенд разбит на кучу компонентов и тоже отдельно. Разве не это базовый принцип докера?

Кто сказал что в моей системе сложно найти ошибку? Я же объяснил что апп сервер у меня атомарен. Не работает - выкинуть из апстрим нахер значит

я не говорил, что сложно) но когда 1 контейнер = 1 сервис, то это очень наглядно видно всё

Я про то, что база отдельно, фронтенд отдельно, бекенд разбит на кучу компонентов и тоже отдельно. Разве не это базовый принцип докера?

И потом эти компоненты общаются через HTTP REST

Впрочем

Почему через REST

msgpack is fine too

я не говорил, что сложно) но когда 1 контейнер = 1 сервис, то это очень наглядно видно всё

ТАК У МЕНЯ ТАК И ЕСТЬ. Только за сервис у меня взята - рабочая еденица.

Ты бы еще юникс утилиты запаковал в докер и приебашил к ним сокет

Ты бы еще юникс утилиты запаковал в докер и приебашил к ним сокет

у меня htop в докере)

Пиздец. Все.

просто если сломается сервер - так проще будет поднять с 0

на сервере только 1 программа - докер

всё остальное в контейнерах

чем больше програм стоит на сервере - тем выше риск того, что обновление системы что-то сломает

а если там просто голая система с 1 единственным докером - тут ничего не сломается

если физического доступа к серверу нет и KVM нет, а только доступ по ssh - это всё ненужные риски

чем больше програм стоит на сервере - тем выше риск того, что обновление системы что-то сломает

точно так же может быть kvm, lxc, lxd, rkt, etc...

а если там просто голая система с 1 единственным докером - тут ничего не сломается

Ну вот да

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

Транзакционно

Не завелось - откатил базовую прямо целиком

Не завелось - откатил базовую прямо целиком

воот

и получилась базовая coreos :D

с докером уже не страшно админить серверы

точно так же может быть kvm, lxc, lxd, rkt, etc...

И сколько человек в мире может так сделать на базе LXC или KVM?

и не страшно ставить апдейты ОС

(И сколько они попросят денег за труд?)

И потом эти компоненты общаются через HTTP REST

Ну вот я о том и говорю, что докер пропагандирует Unix way, микросервисы, одна задача = один контейнер и при этом сам представляет из себя монолитного монстра.

У меня на хосте голая система с lxc.

Problems?

Я еще в поезде еду, так что тут инет пропадает эпизодически.

И сколько человек в мире может так сделать на базе LXC или KVM?

Как так? Поставить lxc на хостовую систему, создать контейнер и накатить все внутри пакетами через тот же ansible? А что тут сложного, в чем rocket since?

Ну вот я о том и говорю, что докер пропагандирует Unix way, микросервисы, одна задача = один контейнер и при этом сам представляет из себя монолитного монстра.

Сам из себя он представляет программу на Golang И ничего не пропагандирует Но attack surface у него большой, это да

Как так? Поставить lxc на хостовую систему, создать контейнер и накатить все внутри пакетами через тот же ansible? А что тут сложного, в чем rocket since?

Атомарно заапдейтить ее теперь

У меня вот стояла Fedora 19 С KVM и более ни с чем

Но атомарно заапдейтить ее до 21 не удалось

Пришлось вообще сносить нахрен

Но то такое

Атомарно заапдейтить ее теперь

Смотря что подразумевается под атомарностью мы пакетами обновляемся. Внутри virtualenv со всеми зависимостями.

Смотря что подразумевается под атомарностью мы пакетами обновляемся. Внутри virtualenv со всеми зависимостями.

сама virtualenv зависит от питона

а питон поменяется после обновления системы

Смотря что подразумевается под атомарностью мы пакетами обновляемся. Внутри virtualenv со всеми зависимостями.

Что подразумевается под атомарностью, можно поглядеть в Project Atomic или в Ubuntu Snappy

Мажорно - нет

ну вот пример из недавней практики - жил был сервачок с 15.10 убунтой) питон стоял через https://github.com/yyuu/pyenv , была пара проектов там, каждый в своей pyenv-virtualenv, запускалось это всё через uwsgi... обновилась система на 16.04 LTS, uwsgi сломался и не захотел заводиться,

Если только на сервере не rolling release дистрибутив