Почему термин DevOps часто упоминают в паре с термином Agile?

Question

[e_asphyx]

И существует ли в природе DevOps фриланс? Или это касается только командной работы?

Answer 1

[Сергей Протько]

Потому что это все buzz words. То есть "модно". Если у тебя нет людей которые называю себя devops-ами - ты не модный. Если ты делаешь не по Agile - ты не модный.

В целом это связанные вещи. Давайте заглянем в вики и посмотрим что это такое:

DevOps (акроним от англ. development и operations) - методология разработки программного обеспечения, нацеленная на активное взаимодействие и интеграцию специалистов по разработке и специалистов по информационно-технологическому обслуживанию.

то есть это когда админы и программисты работают вместе а не по отдельности как обычно. Зачем? читаем дальше:

Методология фокусируется на стандартизации окружений разработки с целью способствования быстрому выпуску релизов.

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

Частые релизы - это нормальное явление в итеративной разработке. А все "Agile" методологии основаны на идеи инкрементных релизов, итеративной разработке, уменьшение цикла обратной связи.

И существует ли в природе DevOps фриланс?

Как мы выяснили ранее - DevOps это методология а не человек. Так что для того что бы у нас был DevOps нам нужны минимум два человека. Или один, который занимается и Dev и Ops.

Вы можете фрилансить в рамках Dev или Ops части и взаимодействовать с другой частью проблемы. В целом же HR-ы понимают под DevOps обычных Ops (админов) и почти никто не парится. А еще в некоторых компаниях упарываются настолько что появляются люди называющие LiveOps. Мол у них все настолько Agile что Ops-ы работают с Dev окружением и Live окружением. Серьезно, мне как-то такое втирали в одной весьма крупной компании.

Comments

[e_asphyx]

Спасибо, круто :)

[Сергей Протько]

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

[e_asphyx]

Так выходит, что научиться этому на маленьких проектах и не выйдет. Я вот даже docker не знаю, куда применить...

[Сергей Протько]

e_asphyx: Docker много куда применять.

Зачем мне нужен Docker?

[Михаил]

Про buzz-word точно очень сказано. 99% людей употребляют этот термин, не понимая, что за ним стоит.
Меня как-то не взяли на работу потому, что при разработке плана инфраструктуры я не сделал Docker. Цитата:
- DevOps должен использовать Docker
- Вам надо оптимальное решение под ваши задачи или вам нужны модные технологии вне зависимости от их уместности?
- Нам нужен DevOps, а не сисадмин
:)

[Сергей Протько]

Михаил: я думаю вы не сильно много потеряли. Хотя мне интересно было бы узнать контекст, а точнее ситуации в которых докер не оптимальное решение.

[Михаил]

Сергей Протько:
много контекстов. Например:
1. IPS/IDS приложение. Docker же приляпает новую сеть. Соответственно все, что ниже третьего уровня пройдет. Promiscous mode вообще не будет работать из контейнера.
2. Любой случай, когда проект серьезный и упаковывают все по правилам (.deb, .rpm).
3. Когда все уже в контейнерах (это как раз описанный мной случай с работодателем) и плодить контейнер в контейнере нет никакого смысла. Потому что даже контейнер первого уровня (BeansTalk) разворачивается так же легко.
Есть и еще варианты.
Серебрянной пули же не бывает :) Если вам показалось, что бывает, значит вы что-то упустили из виду.

[Михаил]

Сергей Протько:
совершенно случайно сейчас наткнулся на интересную статью. спешу поделиться:
https://habrahabr.ru/post/270165/#first_unread

[Сергей Протько]

Михаил:

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

2. а зачем в случае с docker паковать что-то в deb/rpm? Вот честно? Я до перехода на docker тоже в deb паковал но профита в этом по сравнению с возможностью собрать образ я не вижу.

3. Не понял, зачем разворачивать контейнер в контейнере?

p.s. докер не решает всех проблем, во всяком случае приведенный вами первый пункт - я сильно сомневаюсь что стоит даже пытаться это решать как-то с докером. Я думаю тут просто задача включает больше чем докер) А вот два других кейса - мне сложно тут согласится.

p.p.s. Я использую докер не для изоляции процессов а что бы собрать образ, протестировать его и дистрибьютить между окружениями.

[Михаил]

"Обычно это все все же для всего хоста делается, или я не прав?"

Именно. А докерный процесс не имеет при этом доступа к TAP :) Тут можно выкрутиться сделав бридж до докера и подняв траффик до третьего уровня, чтобы netfilter позволил с ним работать, но проделывать эти чудеса ради того, чтобы использовать докер... докер все же - инструмент, а не модная самоцель. И здесь он явно не уместен. Он усложняет архитектуру, не давая ничего взамен.
__________________________
"а зачем в случае с docker паковать что-то в deb/rpm? Вот честно?"

Потому что вы паковали монолитный сервис (какой-нибудь простенький томкат или постргерсс). А что, если в коде также содержатся девелоперские хидеры, например? А если дебаг символы нужно убрать? Вы же не понесете их в прод? А что, если нужно управлять зависимостями (которые не для сборки, а для работы)? Миллион ситуаций.
__________________________

"p.s. докер не решает всех проблем"
Именно! Поэтому его не стоит лепить где попало. Что я и пытался объяснить тем товарищам. Докер отлично помогает в простых приложениях только.

[Сергей Протько]

Михаил:

> докер все же - инструмент, а не модная самоцель

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

> А если дебаг символы нужно убрать? Вы же не понесете их в прод?

тут опять же. Я имею дело с интерпретируемыми языками. И да, я несу в прод все что нужно для дебага просто в продакшене оно не подключается и просто висит мертвым грузом. Но если что я могу взять образ контейнера используемый на сервере, слить себе и дебажить. С дебаг символами и прочим - тут не могу ничего сказать.

> А что, если нужно управлять зависимостями (которые не для сборки, а для работы)?

все зависимости вшиты в образ. Ну во всяком случае я так делаю и в этом есть значительный профит. Один и тот же образ можно задеплоить на разные сервера, протестировать и потом кинуть дальше.

> Поэтому его не стоит лепить где попало.

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

> Докер отлично помогает в простых приложениях только.

Ой ну ладно вам уже, больше похоже что вы бросаетесь в крайности. Мне как разработчику удобно работать с докером. Слил образ, поднял проект, все занимает пару минут. Если вдруг надо что-то админам подправить в инфраструктуре - пыщ пыщ и я просто сливаю новый базовый образ и продолжаю работать. Это удобно в большинстве случаев а не только в простых. Вопрос в том как вы организуете работу в команде и будет ли команде удобно. Я вполне допускаю вероятность при которой докер будет создавать больше проблем для команды.

[Михаил]

Сергей Протько:
Мне кажется, что мы доказываем друг другу одно и тоже. По моему оба согласны, что docker не всегда уместен - об этом же начался диалог. А то, что в других случаях он все же уместен - это я тоже соглашусь. Мне самому он нравится и я использую его для своего личного проекта (на RoR).