Серверное администрирование *

В работе DevOps/Администраторов зачастую возникают моменты, в которые необходимо куда-то кому-то срочно предоставить доступ. Будь то инстанс докера, один из многочисленных контейнеров или какой-то внутренний сервис.

Все знают о возможностях nginx с точки зрения проксирования трафика, балансировки нагрузки между серверами и прочих полезных вещей, помогающих объединять разрозненные сервисы. Однако задача разрешения проблем возникающих в процессе разработки намного обширнее.
Основной посыл данной статьи — показать нестандартный подход к казалось бы простым вещам, таким как предоставление временного доступа внутрь закрытого сегмента.

• Переработанные дэшборды (их много и их можно редактировать)
• Массовый, одновременный сбор элементов данных
• Парсинг полученных данных, включая Regexp, XPath, JSON Path
• Выполнение удаленных команд через прокси
• Шаблоны сетевых устройств из коробки
• Низкоуровневое обнаружение для JMX
• Новые возможности уведомлений
• Переработанный сбор данных по IPMI

Мне очень нравится Terraform.

Помимо CloudFormation для AWS и OpenStack Heat, это один из самых полезных инструментов с открытым исходным кодом, обеспечивающих развертывание и настройку инфраструктуры на любой платформе. Однако есть один способ работы с Terraform, который меня беспокоит:

terraform plan # «Выглядит нормально; в работу!» — подумал инженер.
terraform apply

Может, это и не проблема, если вы разворачиваете софт на одной стойке в дата-центре или тестируете учетную запись AWS с ограниченными правами. В такой ситуации навредить достаточно сложно.

А если развертывание производится из-под всевидящего и всемогущего production-аккаунта или охватывает дата-центр целиком? Мне кажется, это весьма рискованно.

Интеграционное и юнит-тестирование способно решить эту проблему. Вы, наверное, спросите: «Юнит-тестирование — это как для программ?» Да, то самое юнит-тестирование!

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

Введение

Распараллеливание заданий файловой системы

Это рассказ про самописнный велосипед, которым я постарался выполнить главный завет системного администратора — чтобы всё работало, но я ничего не делал. )

Kubernetes — это предназначенный для контейнерной оркестровки фреймворк с открытым исходным кодом. Он был создан с учетом богатейшего опыта Google в области создания сред управления контейнерами и позволяет выполнять контейнеризованные приложения в готовом к промышленной эксплуатации кластере. В механизме Kubernetes много движущихся частей и способов их настройки — это различные системные компоненты, драйверы сетевого транспорта, утилиты командной строки, не говоря уже о приложениях и рабочих нагрузках.

По ходу этой статьи мы установим Kubernetes 1.6 на реальную (не виртуальную) машину под управлением Ubuntu 16.04 примерно за 10 минут. В результате у вас появится возможность начать изучать взаимодействие с Kubernetes посредством его CLI kubectl.

• серверы
  
  
  • настройки безопасности (пользователи, группы, права, межсетевые экраны);
  • установленные приложения и библиотеки;
  • настройки работы приложений (лимиты по дискрипторам, памяти, времени CPU и т.д.);
  • резервное копирование;
  
  
• системы мониторинга за работой прикладного и системного ПО;
• конфигурационные файлы самого продукта, его компонентов, вспомогательных системных и прикладных приложений
• ...

Выпущен 15.5 Update 1 (SP1)

• расширенные возможности автонастройки IP телефонов
• возможность захвата сетевого трафика непосредственно из консоли 3CX
• резервное копирование и восстановление сервера из командной строки
• групповые ящики голосовой почты
• новые возможность веб-клиента 3CX и несколько новых отчетов

• добавлены ссылки на документацию для новых поддерживаемых телефонов (snom D712, Yealink T5X и Yealink CP960)
• добавлена возможность автоматической перезагрузки телефонов snom
• обновлены шаблоны некоторых SIP операторов
• исправлена поддержка второй учетной записи в шлюзе Welltech-ATA172
• в телефоне Fanvil X6 удалены кнопки MWI и HEADSET

Распараллеливание служб сокетов

Самодостаточная система — это та, которая способна восстанавливаться и адаптироваться. Восстановление означает, что кластер почти всегда будет в том состоянии, в котором его запроектировали. Например, если копия сервиса выйдет из строя, то системе потребуется ее восстановить. Адаптация же связана с модификацией желаемого состояния, так чтобы система смогла справиться с изменившимися условиями. Простым примером будет увеличение трафика. В этом случае сервисам потребуется масштабироваться. Когда восстановление и адаптация автоматизировано, мы получаем самовосстанавливающуюся и самоадаптирующуюся систему. Такая система является самодостаточной и может действовать без вмешательства человека.

Как выглядит самодостаточная система? Какие ее основные части? Кто действующие лица? В этой статье мы обсудим только сервисы и проигнорируем тот факт, что железо также очень важно. Такими ограничениями мы составим картину высокого уровня, которая описывает (в основном) автономную систему с точки зрения сервисов. Мы опустим детали и взглянем на систему с высоты птичьего полёта.

Если вы хорошо разбираетесь в теме и хотите сразу всё понять, то система изображено на рисунке ниже.