• «Доклад не имеет права быть скучным»: интервью с Барухом Садогурским о выступлениях на конференциях
    0

    А вы вживую ходили или в записи смотрели?

  • Об админах, девопсах, бесконечной путанице и DevOps-трансформации внутри компании
    +4

    Devops — это идея, из которой вышел некоторый набор практик.
    Это точно не отдельный человек и не роль. Отдельные люди, которых скорее всего и ищут — это:


    • Билд\релиз инженер — человек, который отвечает за сервисы сборки, релиза, деплоя, помогает выстроить процесс сбора обратной связи.
    • Инженер инфраструктурных сервисов — человек, который строит удобное внутреннее\внешнее облако для запуска сервисов. Это он делает мониторинг aaS, базу aaS, сбор трейсинг-спанов aaS, что-то ещё aaS.
    • Инженер по надёжности систем — человек, который радеет за то, что сервис будет работать, редко падать и быстро чиниться. Это он учит людей правильным архитектурным паттернам.

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


    P.S. Системный администратор — это администратор какой-то\каких-то систем. Это нормально — называть сисадминами людей, один из которых рулит флотом серверов на амазоне, а второй отвечает за работоспособность двух серверов 1С-Бухгалтерия и локальной сети. Должности одинаковы, системы (а скорее всего и уровни ответственности\оплаты) — разные.

  • 25 полезных инструментов Kubernetes: развёртывание и управление
    0

    Cabin уже умер, btw.

  • Как не хранить секреты где придётся, или зачем нам Hashicorp Vault
    0

    Так мы не от админа с рут-доступом защищаемся. Мы защищаемся от некоего злоумышленника, который мог получить доступ к хранилищу.

  • Как не хранить секреты где придётся, или зачем нам Hashicorp Vault
    0

    Можно построить, только без веб-gui.

  • Как не хранить секреты где придётся, или зачем нам Hashicorp Vault
    0

    Так эти хранилища решают другие проблемы:
    Аудит
    Настраиваемая гибкость доступа к секретам
    Обслуживание жизненного цикла секретов и доступов
    Безопасность — это вообще сложная тема, тут нет серебряных пуль, которые сделают вашу систему безопасной. Только работа с рисками, только хардкор :)

  • Как не хранить секреты где придётся, или зачем нам Hashicorp Vault
    +1

    Я не понимаю, как ваши слова противоречат статье и паттерну использования Vault.
    Vault не запрещает гибко управлять доступами к секретам. Общность секретов — только в расположении secret/infra/whatever.
    Вы можете и должны делать токены для доступа только к тем секретам, которые необходимы и достаточны для выполнения работ.
    Например у вас есть сервис, который использует все секреты из secret/service_name и только jenkins_api_token из инфраструктурных секретов.


    Вы можете сделать политику


    path "secret/service_name/*" {  
      policy = "read"  
    }
    
    path "secret/infra/jenkins/api_token" {  
      policy = "read"  
    }

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

  • Пособие по Ansible
    +4

    Астрологи объявили неделю Ansible.
    Количество постов про ansible увеличилось втрое.

  • Ansible: тестируем плейбуки (часть 2)
    +4

    Вы понимаете, что смысл этой статьи сводится к
    1) А вот есть Jenkins
    2) А вот Jenkins умеет пуллить изменения в гите
    3) А вот можно затолкать скрипт в дженкинс — и это будет работать
    ?

  • Анонс бесплатного онлайн-курса DevOps: What, Why, and How
    +2
    Технологии развёртывания DevOps.
    Это о чем?
  • Мифы и рецепты Docker
    +3
    Ну вот например настройка лоад-балансера в container-engine — https://cloud.google.com/container-engine/docs/tutorials/http-balancer.
    Нет здесь сценария
    То есть вы отдаете свой контейнер, в котором запакован ваш код, в какое-то мифическое облако, а оно самостоятельно по очереди выключает воркеры из балансера, запускает новые контейнеры и добавляет их в балансер. Сами контейнеры находят внешние сервисы, которые обслуживают стейт(базы, кэша, whatever) и подключают приложения к этим базам.

    Если лично вы не занимались настройкой этого облака под свои нужды — значит это было сделано до вас. Но было. Чудес не бывает. Были бы чудеса — мы бы могли избавиться от наших девопс и опс команд, которые обслуживают _тысячи_ хостов на AWS. Решая все те проблемы, которые, по вашему, из-коробки решаются с помощью докера. Удачи вам в вашем мире. Я пожалуй исключусь из дискуссии.
  • Мифы и рецепты Docker
    +1
    Я вас к тому и веду. ВНЕЗАПНО выясняется, что для того, чтобы облако это умело — системным инженерам нужно позаботиться о паре _небольших_ вещей. Сервис дискавери, распределенные конфиги, автоматика переключения, автоматика деплоя, работа с лоад балансером, очередями. Репликация, бэкапы, отказоустойчивость на уровне датацентров.
    Мне кажется, что это совсем _немного_ выходит за рамки заявленного «Отдать контейнер в облако и оно там все само», но все-таки выходит. Я вас по-прежнему не переубедил?
  • Мифы и рецепты Docker
    0
    И это вполне себе коммерческое облако и я тоже могу прийти со своим контейнером — и мне будет всё тоже самое?
    Можете подсказать название этого облака?
  • Мифы и рецепты Docker
    0
    Действительно высоконагруженые сервисы без облака нынче не мыслимы…

    Если вы внимательно прочитаете мой коммент — вы не найдете противоречий со своим.

    А идея о том, что «отдать контейнер в облако — и пусть оно там все автоматом деплоится и конфигурится» — это пока утопия.

    С чего вы это взяли? Бред же… Это уже давно стандарт ;)

    То есть вы отдаете свой контейнер, в котором запакован ваш код, в какое-то мифическое облако, а оно самостоятельно по очереди выключает воркеры из балансера, запускает новые контейнеры и добавляет их в балансер. Сами контейнеры находят внешние сервисы, которые обслуживают стейт(базы, кэша, whatever) и подключают приложения к этим базам.
    Я все правильно понимаю?
  • Мифы и рецепты Docker
    0
    По-прежнему не понимаю, как у вас контейнеризация позволяет быстро менять железные хосты под бд. Но предположу.
    Сами файлы находятся на внешнем сторадже, который монтируется в сервер и куда смотрит контейнер с субд. При падении сервера, этот же сторадж монтируется в другой сервер, где поднимается такой же контейнер — и все работает.
    Если мое предположение верно — то ключом к успеху тут является внешний сторадж, а не контейнер.
    Если я ошибаюсь — то поясните пожалуйста, интересно.

    Два кейса из тестовой инфраструктуры:
    Кейз один — приложение по-умолчанию запускается на всех физических ядрах, которое находит. Приложение тестируется на машинах с 8 ядрами, у разработчиков тоже всегда 8 ядер или меньше. Новый сервер, 32 ядра — приложение ведет себя не стабильно или не так, как ожидалось(оставим за скобками код, который так работает). Хотя казалось бы тот же образ, тот же код, тот же контейнер.
    Кейз два — приложение всегда работало, не зная про ipv6. Докер работал на ядре, в котором этот механизм был отключен. Новое железо, про эту особенность никто не думал, ipv6 по-умолчанию включен. Сталкиваемся с проблемой резолвинга локалхоста — сначала резолвится ipv6 адрес, который приложение обрабатывать не умеет. А в Докере кстати нельзя убрать ipv6 адрес локалхоста из /etc/hosts, без грязных трюков и он там присутствует даже если у вас в sysctl стоит опция ipv6 all disable и в самом докере вы сказали --ipv6=False. Помогает только отключение на уровня ядра, при загрузке.

    Я понимаю, что никто. Везде trade-off. Я вообще докер не ругаю, я его люблю с версии 0.5 или 0.6.
    Но идеализировать технологию и все пихать в нее — это как-то странно. Всегда важно четко понимать, зачем тащить любую технологию в продакшн.
  • Мифы и рецепты Docker
    0
    Тот, кто отвечает за работу приложения в продуктивной среде.
    Как эта роль называется в конкретной компании\команде — не суть важно.
    Плох тот разработчик, который считает, что его дело — код писать, а как он дальше работает — не его забота.
    Также плох и тот админ, который считает разработчиков идиотами и не в силах настроить коммуникацию с ними так, чтобы требования и нужды эксплуатации принимались во внимание.
  • Мифы и рецепты Docker
    +2
    Если у вас НЕ высоконагруженный сервис — вы конечно можете отдать весь low-level на откуп «контейнерному облаку».
    Для высоких нагрузок и\или сложных сервисов вы ДОЛЖНЫ понимать, что там у этого облака внутри бегает и как оно взаимодействует. Как устроена сеть, как монтируются образы, куда уходят бэкапы, сколько ресурсов у вас реально получается на конкретной виртуалке, как работает балансер(ELB, например), что куда натится, etc. Не всегда вендоры дают эту информацию, но она всегда ценна и полезна.
    А идея о том, что «отдать контейнер в облако — и пусть оно там все автоматом деплоится и конфигурится» — это пока утопия.
  • Мифы и рецепты Docker
    0
    В случае с бд — минимум танцев — это реплика на другой хост с последующим переключением. Докер тут не нужен от слова «совсем».
    Я использую докер для приложений. В них единственный стейт — это версия кода, который бежит внутри. Для этих целей докер — это хорошо. И то не всегда получается без танцев.
    Попробуйте перевезти приложение в докере, которое всегда работало на сервере с 8 ядрами на сервер с 32 ядрами. Или с сервера без поддержки ip v6 на сервер с поддержкой. ВНЕЗАПНО выяснится, что докер не всегда обеспечивает желаемый уровень изоляции от хоста и по-прежнему от него во многом зависим.
  • Мифы и рецепты Docker
    0
    Зачем вообще постгрес держать в контейнере? В чем глубинный смысл? Версию бд все-равно без танцев с бубном не обновить.
  • Как контролировать наличие ключевых слов на сайте
    –1
    Любой спец накидает скрипт для подобного на коленке за 5-10 минут. А это сервис с GUI для тех, кто не обладает подобной экспертизой.
  • Какой язык программирования будет наилучшим для изучения в 2015 году?
    0
    CSS — есть
    SQL — есть
    Нужно добавить HTML.
  • Salt и Ansible — системы управления конфигурацией на языке Python — видео с DevConf 2014
    –1
    Кроме вопроса о реальной необходимости ставить screen и bash c переменными — в случае с ansible вам нужно было просто разбить все эти установки на роли. И выглядело бы оно как
    roles:
    — { role: bash, var: 'foo' }
    — screen
    — wget
    — vim
  • 7 удивительных фактов о профессиональной ориентации
    0
    После десятка вполне определенных книг я полностью переосмыслил свой подход к менеджменту. После нескольких книг и семинаров. открыл свой бизнес. После двух конкретных видео-курсов, бизнес заколосился с новой силой.

    Можете рассказать про эти книги, семинары и видео-курсы?
  • Автоматизируем и ускоряем процесс настройки облачных серверов с Ansible. Часть 4: работаем с модулями
    +3
    Перевод официальной документации мало кому интересен. Таких статей в интернете и так уже достаточно. Даже на хабре. Гораздо более интересен реальный опыт продакшна, реальные проблемы, возникшие в процессе работы и реальные способы их решения.
  • Автоматизируем и ускоряем процесс настройки облачных серверов с Ansible. Часть 3: Переменные и файл inventory
    0
    Основная проблема с переменными в ansible — что их можно много где описывать — и потом огрести проблемы с поддержкой. Поэтому необходимо с момента начала реальной эксплуатации вырабатывать некие правила работы с переменными.

    Поделюсь своими наработками:
    Максимум переменных выносим в роли, из них большинство должно находится в role/defaults/main.yml, то-есть быть переменными по-умолчанию.

    Если у вас много переменных, завязанных на конкретный проект|сервис, а роль используется для многих проектов|сервисов, то пока лучшее решение, что я нашел — это напротив хоста или в группе хостов ставить переменную project=bla, а внутри роли импортировать в переменных массив такого вида:
    role_foo_vars:
      - { project: 'bla', var1: '/var', var2: 'user', var3: 'group', var4: '42', var5: 'httpd' }
      - { project: 'bar', var1: '/var', var2: 'user2', var3: 'group2', var4: '42', var5: 'apache2' }
    

    в плейбуке строить шаги следующим образом:
        file: path={{ item[0].var1 }} owner={{ item[0].var2 }} group={{ item[0].var3 }} state=directory
        with_nested:
          - role_foo_vars
          - project
        when: "item[0].project == item[1]"
    

    этот шаг будет использовать переменные var1, var2 и var3 из массива, где в переменной project стоит необходимое значение (в нашем случае — bla).
  • Автоматическая конфигурация: практика применения CFEngine в реальном мире
    0
    А можете пояснить, для чего в 2015 году только выбирающий себе CM-систему человек, может заинтересоваться cfengine и обойти стороной chef, puppet, ansible и salt?
    Не сарказм.
  • Автоматизируем и ускоряем процесс настройки облачных серверов с Ansible. Часть 2: вывод, отладка, и повторное использование playbook
    +1
    У вас же машина поднимается посредством ваших скриптов? Почему бы этими же скриптами не запускать с управляющей машины плейбук провижининга против нового хоста?
  • Автоматизируем и ускоряем процесс настройки облачных серверов с Ansible. Часть 1: Введение
    0
    У нас порядка 400. А какие велосипеды писали, для чего, поделитесь? Нас ansible полностью устроил, основная проблема была в утрясании workflow, много итераций прошли в этом процессе.
  • Автоматизируем и ускоряем процесс настройки облачных серверов с Ansible. Часть 1: Введение
    0
    Про идемпотентность:
    Все зависит от вашего стиля написания плейбуков. Если вы использовали raw: wget foo.bla/file — то файл будет скачиваться каждый раз. Если же вы используете модуль get_url — то он будет проверять наличие и хэш файла перед скачиванием. Мы же в своей работе обычно пишем вначале стек проверок и заносим результаты в переменные. После чего в каждом шаге есть проверка вида «если nginx -v != заданной версии nginx — то берем собранный пакет и ставим. Если же nginx -v = заданной версии — то скипаем шаг. У нас, например, все роли обеспечивают идемпотентность.

    Про кучу серверов единовременно:
    У нас такой задачи не стоит обычно, но сами разработчики рапортуют об успешных инсталяциях на инфраструктурах в десятки тысяч машин. Можно запускать по очереди, по 10-20 хостов за раз. Можно отправить все задачи в кролика — и кем-то их разбирать. Архитектуры, которые решают подобные задачи уже изобретены.
  • Катастрофоустойчивость: DR для малых предприятий, энтузиастов и прочих гиков с помощью Microsoft Azure
    0
    Заголовок забавно звучит в свете недавних событий с падением Azure.
  • Сборка пакетов библиотек для rpm-based дистрибутивов Linux
    0
    Он простой, как три копейки. Например собрать собственный rpm-пакет из папки можно так(пример из оф. вики):
    fpm -s dir -t rpm -n «slashbin» -v 1.0 /bin /sbin
    Эта команда пакетирует все файлы из директорий /bin и /sbin в rpm-пакет slashbin версии 1.0.
    В fpm нет огромных манов, это удобный инструмент от того, кто устал генерить валидные spec-файлы и всё, что там еще надо, для таких же уставших.
    Если вы не мейнтейнер каких-то пакетов — то вся это возня вам практически наверняка не нужна.
  • Сборка пакетов библиотек для rpm-based дистрибутивов Linux
    +1
    Зачем это всё, если есть fpm?
  • Поднятие chroot-«виртуалки» с ubuntu для сборки пакетов
    0
    Попробуйте хороший инструмент — github.com/jordansissel/fpm
  • Несколько версий PHP под одним Apache на Windows
    +1
    Заголовок вызывает несколько приступов боли.
  • Как установить PostgreSQL 9.4 на Raspberry Pi, Radxa или другие подобные микрокомпьютеры под управлением Lubuntu
    +3
    Но зачем?
  • Наш велосипед или скрипты, облегчающие жизнь админа
    0
    Почему не используете взрослые CM-системы?
  • С днём системного администратора
    +1
    С праздником коллеги! Повкуснее серверов вам!
  • Хочу поздравить всех коллег с Днем Программиста
    0
    С праздником господа! Всем добра!
  • 15000 день unix эпохи
    +2
    Будем кидать флоппи-дисководы через плечо в форточку ;-)
  • Скорость и тип оплаты вашего домашнего интернета
    0
    У нас в Новокузнецке 10 мегабит для физиков — 700 рублей.
    А для юриков от них же 4 мегабита за 6 килорублей.
    Сибирь, снега, медведи. На данный момент только-только растаял снег в городе ;-)