Первые двое могут деплоить конфигурацию на прод, следующие двое могут делать пуллреквесты к ней.

Цифры "двое" - утрированы и поддаются адекватному масштабированию.

Чё не так-то? Дмитий дело-же говорит. Я тоже к этому команды двигаю. На прод, выкатывается только с master, в master непозволено пушить никому кроме тимлида и суперадмина. Защищённые ветки же. Ключи для выкатки и т.п. в gitsubmodule на которые пермишины только у суперадмина и тимлида.

*Дмитрий (надо завязывать с беспроводной клавой)

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

а разрабы неделающие инит скрипты для своего софта это нормально

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

да и расширять знания им полезно

На моей памяти опыт в настройке серверной части прямо пропорционально зависит скиллу программирования и правильности применяемых продходов.

На моей памяти опыт в настройке серверной части прямо пропорционально зависит скиллу программирования и правильности применяемых продходов.

которые также коррелируют с опытом работы с различными уровнями технологического стека

На моей памяти опыт в настройке серверной части прямо пропорционально зависит скиллу программирования и правильности применяемых продходов.

Нет

Роман, а вы читали пару моих историй вчера?

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

359 новых сообщений, у вас тут хардкор начался наконец?

хардкор это 600 в час

плохой мик вс хороший мик

:)

> Dmitrii А если вовлекать разработчика к конфигурированию у него целый новый мир открывается. мой опыт говорит, что такое удается около в 20 % команд, в остальных буксует по вполне уже объекивным причинам. Основная причина в том, что программист должен держать в коде свое рабочее окружение (например поднимать проект в вагранте), а это требует затрат времени и усилий, а когда сложность проекта переходит некоторую грань, то становится совсем невозможно. Это как с тестами, но с тестами 80 процентов каверадж вполне ок, а с кодом инфраструктуры такое не прокатит

Приетствую, форумчане! Че почитать по архитектурам? The DevOps 2.0 пока читаю, думаю что потом глянуть

можно читать этот чат, тут пишут чего делать не стоит

Да, видел я такие инфраструктуры, где была одна база и порядка 20 си-демонов на девелопменте на 100 разработчиков и их 100 виртуальных машин. (не шучу)

Там наверное об этом и не стоит мечтать.

я вендаадмин же

ну хотел им стать я ж грил

ну потом сдал mcsa

и передумал

я подумал так - я лучше ваще не ит буду заниматься

чем вендой

Хехе

Вхахаххаахах

Приетствую, форумчане! Че почитать по архитектурам? The DevOps 2.0 пока читаю, думаю что потом глянуть

ruhighload.com ? :)

ruhighload.com ? :)

Это замечательно. Это я видел)

ruhighload.com ? :)

5 советов по использованию SVN Небольшие советы для упрощения работы с Subversion

кек

=)

5 советов по использованию SVN Небольшие советы для упрощения работы с Subversion

git . . . Profit!

git-svn еще

Как хорошо, что я молодой и весь этот треш почти не застал :)))

Но svn еще "зацепил", да.

Господа, а сетевой wait входит в iowait ? или как его смотреть ?

Первая ссылка в гугле: http://serverfault.com/questions/37441/does-iowait-include-time-waiting-for-network-calls

Не то часом?

Господа, а сетевой wait входит в iowait ? или как его смотреть ?

мне кажется, такое лучше вчего смотреть strace или sysdig

Node 6.0 is out! :)

не входит, пока нет nfs или iscsi или подобного

смотреть проще всего с ss -s

teamcity

ОМГ :)

Ну вы намолотили

Ладно, про докер и LXC я скажу

Смотрите У меня приложение на Perl

В нем херова гора модулей, как принято у перловиков

Раскатка контейнеров под разбор очереди в LXC энсиблом тупо может занять 40 минут или час

Пока там все модули соберутся

А будь у меня докер - у меня был бы отдельный слой с уже собранными модулями

И раскатка контейнеров шла бы сильно быстрее

Вы можете спросить - а почему вообще такая проблема возникла?

cpan не?

А вот так вышло исторически

cpan не?

Ну - cpan

Чет я не припомню чтоб оттуда долго модули ставились

Или их ну ваааще дохера?

Ваще дохера

Там обычно первый запуск тупняковый.

И когда ставится восемь контейнеров на одну тачку И все компилится и молотятся тесты еще

Это 40 минут ада

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

Так в LXC же можно делать базовые образы... Хотя это конечно очень начинает быть похоже на докер. Или докер на LXC

Но докер эту проблему тоже решает

Так в LXC же можно делать базовые образы... Хотя это конечно очень начинает быть похоже на докер. Или докер на LXC

Ну так я и говорю - тут решений разных сразу на ум приходит штуки четыре

Но лучшим представляется докер

Потому что кроме снятия этой проблемы, докер снимает еще две

Первое - повторимость набора перловых модулей на относительно долгом промежутке времени

(фиксить версии в сипанфайле бесполезно - их сносят с публикации)

Второе - один и тот же имадж на тестинге, стейджинге и проде

Первое - повторимость набора перловых модулей на относительно долгом промежутке времени

За счет введения базового слоя с набором модулей Редко обновляемого

Да, соглашусь, с Perl заход грмотный получился в пользу докера, но немного похож на предложеный юз-кейс выше - "запаковать кусок говнокода" ?

Я год давным давно писал под вёб на перле. Когда этих ваших докеров и даже LXC ваще еще небыло. Это была боль конечно.

Ну я вот и поныне пишу под веб на перле

И не только под веб

Да не только с перл, вообще с любыми зависимостями тянущимися с тырнету - спас в замопроженном имадже от которого можно скакать.

просто в докер управление и наследование этих образов поуму реализовали.

Тут такое дело просто, вот в PHP все зависимости тянутся через composer и как бы являются частью приложения. Поэтому никому в голову не приходит их все в имедж паковать

А в перли с этим их сипаном, оно втыкается в системные каталоги и вот

В перле*

А вот скажите, вот в Амазоне есть такое понятие как AMI образы. Можно даже свои создавать.

Зачем тогда мне докер?

Селяви - "а дайка я свой пакетный менеджер с бекджеком и шлюшками запилю"

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

Или оно как бы не пересекается?

Я просто хочу разобарться, в конце-концов для каких задач докер все же подходит :)

Получается что если у меня не Амазон то дорога в докер, а если Амазон то AMI?

ну с ami у тебя зависимость от amazon с docker чуть больше независимости

Ну плате vendor lock - ясно, да. Но в принципе если не броть это в расчет то что лучш ето тогда?

ну вот посчитал твой начальник, что бабла на амазаон уходит больше чем на digital ocean или на azure и сказал - ребят в год это же такая экономия - съезжаем!