…
В связи с произошедшей утечкой информации о дислокации секретных в/ч, предлагаю выделить 78 341 931 000 рублей на переброску этих в/ч в другие районы со строительством соответствующей инфраструктуры.
…
Нужно учитывать, что в США тоже есть инфляция и за 50 лет доллар подешевел примерно в 7-10 раз. То есть по нынешним ценам это будет около $300, что выглядит уже более солидно чем $33.
MySQL и PHP они используют именно потому что слишком сильно с ним связаны — перейти на что-то другое им теперь сложно, поэтому они изобретают костыли с MySQL и патчат PHP.
Спасибо вам за пример, это именно то, о чем я хотел предупредить в статье — сначала подумайте, а потом выберите инструмент, возможно проще сразу написать свое.
Очень много кастомного в сервисе, правда.
Про windows — не было практически ничего для Chef. Абсолютно ничего. Пользователи-группы — не было нужно, а вот поставить галочку в IIS даже руками не сразу найдешь в настройках — видимо.никому не было нужно.
Под Linux — создать пользователя-группу не так сложно даже на bash. Но вы абсолютно правы про срезанные углы — некоторые вещи иногда аукались. Веб-сервера — там больше проблем с настройками, сами пакеты через rpm ставятся довольно просто. А вот настройки в конфигах тоже очень хитровымученные. Девелоперы у нас тоже талантливые были…
Нам в любом случае пришлось писать рецепты под нас. Готовых мы не нашли.
Универсальность нужна для продажи продукта, а для внутренних целей продукт, заточенный под себя гораздо удобнее.
А что касается «главного вопроса» — я уволился год назад. Система работает и развивается.
Проблема аналогична любой такой же из разработки ПО — качество кода и документации должно позволять другим разработчикам понять как оно работает. Не все идеально, но не все и плохо.
Коллеги, пожалуйста, подождите торопить. Я планировал выкладывать понемногу, но меня уже попросили бахнуть все сразу.
Я сейчас дописываю все идеи и в течение дня-двух выложу остальное.
Мысли копились на протяжение нескольких лет, я не профессиональный писатель и все идет довольно сумбурно, так что, пожалуйста, подождите критиковать.
Если тема интересна, мне кажется, вы вполне пока можете обсудить уже существующие вопросы, я постараюсь учесть замечания по ходу написания.
Да, скорее всего.
В итоге все меньше преимуществ «из коробки» и все больше самописных костылей.
Кстати, хотелось бы узнать, как обычно у коллег решаются такие вопросы:
* есть вы, кто пытается автоматизировать хаос в деплойменте
* есть программист, который пишет сервис A на Erlang
* есть программист, который пишет сервис B на NodeJS
* есть программист (который работает тут уже 15 лет) на языке C, пишущий сервис C. Он звезда и может сказать вам где этот ваш руби он крутил вместе с вами.
Ну, допустим, есть еще десяток разных сервисов — от MSSQL до Java…
Кто должен описывать скрипты для установки этих сервисов?
То есть постоянно перебрасывать сервер между environment'ами? Да, выход, для небольшого количества серверов.
Но не очень красиво, особенно если environment'ы уже используются по прямому назначению.
Могут возникнуть вопросы — а что делать если на один сервер нужно поставить два сервиса разных версий (в вашем случае environment'ов)?
Подходящих продуктов может и не быть, процесс компании может не захотеть меняться, а «небольшое количество кода» всегда вырастает в «большое количество кода» и в итоге мы получаем все-таки написанное свое, но с большим количеством костылей вокруг части, которую мы поменять не можем.
Например, для Windows не было и до сих пор не так уж много инструментов для глубокой настройки системы. Несколько лет назад в стандартной поставке появился PowerShell и начали появляться какие-то сниппеты, которые могут облегчить настройку. Но 5 лет назад их не было.
В Chef еще два года назад невозможно было под Windows подмонтировать сетевой ресурс с доменным юзером, например, или без буквы диска. Можно было вызвать «net use» и ловить вывод, да. Но это несерьезно.
Powershell или bash, или Ruby, или C++ для желающих — все части нужно между собой состыковывать. Bash-скрипт, запускающий python-процесс, запускающий ruby-скрипт, который запускает ruby-скрипт, который запускает bash-скрипты, которые вызывают cmd-файл под windows — через это мы проходили. Цепочка была чуть длиннее, а для linux чуть короче, но как программист, я испытываю содрогание от таких вещей, а как системный администратор — начинаю подсчитывать количество пакетов, которые нужно иметь установленными.
Да, поначалу пришлось строить лес с помощью костылей поверх Chef. Но в определенный момент понимаешь что количество своих костылей больше количества полезных фич, которые предлагает тот или иной инструмент.
Проблемы могут приходить и изнутри — версии двух пакетов внезапно могут быть одинаковыми, но разрабатываться в разных бранчах.
А сколько, как вы думаете, может продолжаться разговор о том что нам нужен внутренний репозиторий для каждого окружения?
Да, вот именно множество версий — одна из основных проблем, которую с помощью Chef решить не так просто.
По поводу продолжения — вас понял. Сейчас дописываю третью часть, но, наверное, объединю вторую и третью, а потом постараюсь урезать бьющий поток мыслей и все уместить в последнюю часть.
Слишком уж радужно там все описано про пользу.
www.popmech.ru/science/13464-maslo-maslyanoe-zhiry
www.popmech.ru/science/14890-zhirnyy-vopros
upd: я буду обновлять страничку перед добавлением комментария…
В связи с произошедшей утечкой информации о дислокации секретных в/ч, предлагаю выделить 78 341 931 000 рублей на переброску этих в/ч в другие районы со строительством соответствующей инфраструктуры.
…
Вот так и романтизируют люди профессию :)
Спасибо вам за пример, это именно то, о чем я хотел предупредить в статье — сначала подумайте, а потом выберите инструмент, возможно проще сразу написать свое.
Про windows — не было практически ничего для Chef. Абсолютно ничего. Пользователи-группы — не было нужно, а вот поставить галочку в IIS даже руками не сразу найдешь в настройках — видимо.никому не было нужно.
Под Linux — создать пользователя-группу не так сложно даже на bash. Но вы абсолютно правы про срезанные углы — некоторые вещи иногда аукались. Веб-сервера — там больше проблем с настройками, сами пакеты через rpm ставятся довольно просто. А вот настройки в конфигах тоже очень хитровымученные. Девелоперы у нас тоже талантливые были…
Универсальность нужна для продажи продукта, а для внутренних целей продукт, заточенный под себя гораздо удобнее.
А что касается «главного вопроса» — я уволился год назад. Система работает и развивается.
Проблема аналогична любой такой же из разработки ПО — качество кода и документации должно позволять другим разработчикам понять как оно работает. Не все идеально, но не все и плохо.
Я сейчас дописываю все идеи и в течение дня-двух выложу остальное.
Мысли копились на протяжение нескольких лет, я не профессиональный писатель и все идет довольно сумбурно, так что, пожалуйста, подождите критиковать.
Если тема интересна, мне кажется, вы вполне пока можете обсудить уже существующие вопросы, я постараюсь учесть замечания по ходу написания.
В итоге все меньше преимуществ «из коробки» и все больше самописных костылей.
Кстати, хотелось бы узнать, как обычно у коллег решаются такие вопросы:
* есть вы, кто пытается автоматизировать хаос в деплойменте
* есть программист, который пишет сервис A на Erlang
* есть программист, который пишет сервис B на NodeJS
* есть программист (который работает тут уже 15 лет) на языке C, пишущий сервис C. Он звезда и может сказать вам где этот ваш руби он крутил вместе с вами.
Ну, допустим, есть еще десяток разных сервисов — от MSSQL до Java…
Кто должен описывать скрипты для установки этих сервисов?
Но не очень красиво, особенно если environment'ы уже используются по прямому назначению.
Могут возникнуть вопросы — а что делать если на один сервер нужно поставить два сервиса разных версий (в вашем случае environment'ов)?
Например, для Windows не было и до сих пор не так уж много инструментов для глубокой настройки системы. Несколько лет назад в стандартной поставке появился PowerShell и начали появляться какие-то сниппеты, которые могут облегчить настройку. Но 5 лет назад их не было.
В Chef еще два года назад невозможно было под Windows подмонтировать сетевой ресурс с доменным юзером, например, или без буквы диска. Можно было вызвать «net use» и ловить вывод, да. Но это несерьезно.
Powershell или bash, или Ruby, или C++ для желающих — все части нужно между собой состыковывать. Bash-скрипт, запускающий python-процесс, запускающий ruby-скрипт, который запускает ruby-скрипт, который запускает bash-скрипты, которые вызывают cmd-файл под windows — через это мы проходили. Цепочка была чуть длиннее, а для linux чуть короче, но как программист, я испытываю содрогание от таких вещей, а как системный администратор — начинаю подсчитывать количество пакетов, которые нужно иметь установленными.
Собственно, статья и писалась для того, чтобы описать одни грабли и показать с какой стороны на них можно наступать и сколько раз.
Проблемы могут приходить и изнутри — версии двух пакетов внезапно могут быть одинаковыми, но разрабатываться в разных бранчах.
А сколько, как вы думаете, может продолжаться разговор о том что нам нужен внутренний репозиторий для каждого окружения?
По поводу продолжения — вас понял. Сейчас дописываю третью часть, но, наверное, объединю вторую и третью, а потом постараюсь урезать бьющий поток мыслей и все уместить в последнюю часть.