Привет %username%,
Сегодня я хотел бы рассказать про достаточно тривиальную задачу сбора логов с децентрализованных Squid proxy серверов и подводные камни с которыми мы столкнулись.
Что имеем:
Про вас не снимают фильмов, не пишут песен и часто даже не знают в лицо. Образ сисадмина оброс мифами: небрит, нетрезв и неотёсан.
Знаменитые мистификаторы! Вы создали эти легенды, чтобы нести свой крест в одиночестве. Но раз в году, стряхнув стереотипы, вы выходите к юзерам, чтобы принять благодарности.
Рыцари в сияющих доспехах, повелители офиса и атланты IT-инфраструктуры. На вас все компьютеры, сети, серверы, роутеры, концентраторы, коммутаторы и шлюзы.
Сегодня мы преклоняемся перед вами и приносим дары:
Всем привет! Меня зовут Олег и я SRE. В какой-то момент мне захотелось улучшить свои навыки программирования на Go и написать маленькую многопользовательскую игру.
Заниматься веб-анимацией или писать приложение под мобильную платформу мне не хотелось, поэтому я решил в качестве клиента использовать любимый инструмент сисадминов — telnet.
Вот что получилось:
После выхода Ubuntu 16.04 (новый LTS релиз), systemd стал реальностью всех основных дистрибутивов Linux, использующихся на серверах. Это означает, что можно закладываться на расширенные возможности systemd, не рискуя оставить часть пользователей приложения «за бортом».
Этот пост о том, как реализовать многоворкерное приложение средствами systemd.
Abstract: Использование шаблонов сервисов и target'ов для запуска нескольких инстансов сервиса (реализация «воркеров»). Зависимость PartOf. Немного про [install] секцию у unit'ов.
Многие языки программирования с плохой или никакой многопоточностью (Python, Ruby, PHP, довольно часто C/C++) используют концепцию «воркера». Вместо того, чтобы городить сложные отношения между тредами внутри приложения, они запускают несколько однопоточных копий приложения, каждое из которых берёт на себя кусок нагрузки. Благодаря опции SO_REUSEPORT есть даже возможность «вместе» слушать на одном и том же порту, что покрывает большинство задач, в которых возникает потребность в воркерах (собственно, обычные серверные приложения, реализующие API или обслуживающие веб-сайт).
Но такой подход требует наличия «супервизора», который отвечает за запуск копий, следит за их состоянием, обрабатывает ошибки, завершает при всякого рода stop/reload и т.д. При кажущейся тривиальности — это совершенно не тривиальная задача, полная нюансов (например, если один из воркеров попал в TASK_UNINTERRUPTIBLE или получил SIGSTOP, то могут возникнуть проблемы при restart у не очень хорошо написанного родителя).
Есть вариант запуска без супервизора, но в этом случае задача reload/restart перекладывается на администратора. При модели «один процесс на ядро» перезапуск сервиса на 24-ядерном сервере становится кандидатом в автоматизацию, которая в свою очередь требует обработки всех тех же самых SIGSTOP и прочих сложных нюансов.
Одним из вариантов решения проблемы является использование шаблонов сервисов systemd вместе с зависимостью от общего target'а.
Читать полностью »
SparrowHub — проект, целью которого является распространение различных готовых решений для задач системного администрирования и не только.
Несмотря на то, что существует масса решений по автоматизации задач системного администрирования, определенная ниша в этой области все же остается незанятой. Что мы делаем, когда хотим решить какую-то специфическую задачу? Например, проверить логи нашего ssh сервиса на наличие неудачных попыток логинов с целью позаботиться о секьюрности наших серверов? — Берем и пишем однострочник, состоящий из bash команд вида grep, sed, awk и так далее, ну, или можем написать скрипт на Perl. Отлично, все работает. Eсть решение, которое устраивает нас. И мы пользуемся им. Вопрос в том, как мы хотим сохранить результаты наших трудов, что бы поделиться ими с другими или же когда пройдет время снова воспользоваться придуманным решением. Вот тут и возникает проблема. Читать полностью »
Здесь минимум теории, в основном практическая часть. Описывается как настроить WinRM, как изменить профиль сетевого адаптера, дается скрипт по добавлению в TrustedHosts с фильтрацией, объясняется зачем нужны доверенные хосты, и рассматриваются поверхностно удаленные подключения так чтобы можно было сесть и сразу админить удаленные машины.
Наиболее простой путь сконфигурировать удаленное управление это выполнить Enable-PSRemoting в оболочке powershell с правами администратора. При этом произойдет следущее:
В первой части мы начали изучение Ansible, популярного инструмента для автоматизации настройки и развертывания ИТ-инфраструктуры. Ansible был успешно установлен в InfoboxCloud, описаны принципы работы, базовая настройка. В завершении статьи мы показали как быстро установить nginx на несколько серверов.
Во второй части мы разобрались в выводе playbook, научились отлаживать и повторно использовать скрипты Ansible.
В третьей части мы узнали как написать единый Ansible playbook для разных ОС (например с rpm и deb), как обслуживать сотни хостов и не писать их все в inventory и как сгруппировать сервера по регионам InfoboxCloud. Было изучено использование переменных Ansible и файла inventory.
В четвертой части мы научились использовать модули Ansible для настройки сервера: разобрались, как запускать самые обычные скрипты на удаленных серверах в InfoboxCloud, использовать шаблонизацию для файлов конфигурации, подставляя необходимые переменные, и как использовать системы управления версиями для получения кода на сервер.
В этой части мы рассмотрим, как запускать задачу локально в рамках playbook для удаленных серверов, как использовать условия для выполнения конкретных задач только в определенной ситуации, как использовать циклы для значительного сокращения количества задач в playbook. В завершении мы разберем, как организовывать playbook в роли.
Читать полностью »
В первой части мы начали изучение Ansible, популярного инструмента для автоматизации настройки и развертывания ИТ-инфраструктуры. Ansible был успешно установлен в InfoboxCloud, описаны принципы работы, базовая настройка. В завершении статьи мы показали как быстро установить nginx на несколько серверов.
Во второй части мы разобрались в выводе playbook, научились отлаживать и повторно использовать скрипты Ansible.
В третьей части мы узнали как написать единый Ansible playbook для разных ОС (например с rpm и deb), как обслуживать множество хостов и не писать их все в inventory, и как сгруппировать сервера по регионам облака. Было изучено использование переменных Ansible и файла inventory.
В этой части мы научимся использовать модули Ansible для настройки сервера: разберемся, как запускать самые обычные скрипты на удаленных серверах, использовать шаблонизацию для файлов конфигурации, подставляя необходимые переменные, и как использовать системы управления версиями для получения кода на сервер.
Читать полностью »
В предыдущей статье мы начали изучение Ansible, популярного инструмента для автоматизации настройки и развертывания ИТ-инфраструктуры. Ansible был успешно установлен в InfoboxCloud, описаны принципы работы, базовая настройка. В завершении статьи мы показали как быстро установить nginx на несколько серверов.
В этой статье мы продолжим изучение Ansible: разберем вывод playbook, научимся отлаживать их и разделять для удобства повторного использования.
Читать полностью »
Ansible – популярный инструмент для автоматизации настройки и развертывания ИТ-инфраструктуры.
Основные задачи, которые решает Ansible:
По сравнению с другими популярными инструментами автоматизации ит-инфраструктуры, Ansible не требует установки клиентских приложений на обслуживаемые сервера, что может сократить время настройки перед развертыванием инфраструктуры. Для работы Ansible подключается к обслуживаемым серверам по SSH.
Читать полностью »
