Существует негласное правило, согласно которому не рекомендуется создавать более 5-6 тысяч почтовых ящиков на одном сервере с Zimbra Collaboration Suite. Превышение этого диапазона чревато значительным ухудшением качества работы сервера и снижением его доступности для пользователей. Но что делать, если у вас в ведении находится крупное предприятие или SaaS-провайдер, продающий доступ к Zimbra Collaboration Suite как услугу, и вам требуется обеспечить электронной почтой 10, 20, 30 и более тысяч человек? Специально для таких случаев в Zimbra существует поддержка мультисерверной установки, при которой почтовые ящики находятся на разных серверах и позволяют сохранять высокую доступность электронной почты даже при больших нагрузках.

Полгода назад мы закончили миграцию всех наших stateless сервисов в kubernetes. На первый взгляд задача достаточно простая: нужно развернуть кластер, написать спецификации приложений и вперед. Из-за одержимости в вопросе обеспечения стабильности в работе нашего сервиса пришлось сразу начать разбираться с тем, как работает k8s и тестировать различные сценарии отказов. Больше всего вопросов у меня возникало ко всему, что касается сети. Один из таких "скользких" моментов — работа сервисов (Services) в kubernetes.

В документации нам говорят:

• выкатите приложение
• задайте liveness/readiness пробы
• создайте сервис
• дальше все будет работать: балансировка нагрузки, обработка отказов итд.

Но на практике все несколько сложнее. Давайте посмотрим, как оно работает на самом деле.

Прим. перев.: Статья написана Javier Salmeron — инженером из хорошо известной в Kubernetes-сообществе компании Bitnami — и была опубликована в блоге CNCF в начале августа. Автор рассказывает о самых основах механизма RBAC (управление доступом на основе ролей), появившегося в Kubernetes полтора года назад. Материал будет особенно полезным для тех, кто знакомится с устройством ключевых компонентов K8s (ссылки на другие подобные статьи см. в конце).


Слайд из презентации, сделанной сотрудником Google по случаю релиза Kubernetes 1.6

Многие опытные пользователи Kubernetes могут вспомнить релиз Kubernetes 1.6, когда авторизация на основе Role-Based Access Control (RBAC) получила статус бета-версии. Так появился альтернативный механизм аутентификации, который дополнил уже существующий, но трудный в управлении и понимании, — Attribute-Based Access Control (ABAC). Все с восторгом приветствовали новую фичу, однако в то же время бесчисленное число пользователей были разочарованы. StackOverflow и GitHub изобиловали сообщениями об ограничениях RBAC, потому что большая часть документации и примеров не учитывали RBAC (но сейчас уже всё в порядке). Эталонным примером стал Helm: простой запуск helm init + helm install больше не работал. Внезапно нам потребовалось добавлять «странные» элементы вроде ServiceAccounts или RoleBindings ещё до того, как разворачивать чарт с WordPress или Redis (подробнее об этом см. в инструкции).

Всем привет!

Часто в организациях используем разного рода прокси, прокси как составляющая программного шлюза или самостоятельный классический вариант squid + анализатор логов и т.п.

Мы пытались внедрить решение от Ideco и ИКС, в итоге остановились на squid. Под катом история пути и техническая информация по настройке старого доброго кальмара.

Развертываение kubernetes HA с containerd

Добрый день уважаемые читатели Хабра! 24.05.2018 г. в официальном блоге Kubernetes была опубликована статья под названием Kubernetes Containerd Integration Goes GA, в которой говорится, что интеграция containerd с Kubernetes готова к production. Также ребята из компании Флант в своем блоге разместили перевод статьи на русский язык, добавив немного уточнений от себя. Почитав документацию проекта на github, я решил попробовать containerd на "собственной шкуре".

У нас в компании есть несколько проектов в стадии "до продакшена еще очень далеко". Вот они и станут нашими подопытными; для них мы решили попробовать развернуть отказоустойчивый кластер Kubernetes с использованием containerd и посмотреть, есть ли жизнь без docker.

Если Вам интересно посмотреть, как мы это делали и что из этого получилось, — добро пожаловать под кат.

В данный момент инсталяция по данному мануалу работать не будет. Из за больших изменений API Kubemaster, в данный момент я готовлю новый цикл статей где будут рабочие версии мануалов
Первая из статей habr.com/ru/post/462473

Здравствуйте!

В данной публикации я хотел бы рассказать о кластере Kubernetes с высокой доступностью (HA).



Оглавление:

1. Вступление
2. Список используемого софта
3. Список и назначение хостов
4. Принцип работы и развертывания
5. Подготовка ОС к развертыванию. Установка docker, kubeadm, kubelet и kubectl
6. Подготовка конфигурационного скрипта
7. Создание etcd кластера
8. Инициализация мастера с помощью kubeadm
9. Настройка CIDR
10. Инициализация остальных мастернод
11. Настройка keepalived и виртуального IP
12. Добавление рабочих нод в кластер
13. Установка ingress-nginx
14. Дополнительно
    
    • Dashboard
    • Heapster
    
    

Последняя часть руководства. Внутри бонусные главы, немного новых фотографий, и главное — pdf с руководством которое можно скачать и поделиться с другом.

Если такая заявка в вашей системе сервис-деска вызывает дергающийся глаз и падение тонуса ― у вас наверняка еще не настроено удобное централизованное управление принтерами. Пора исправлять эту неувязочку.

Статья скорее для тех, у кого нет этого сферического корпорейта в вакууме, с виртуальными принтерами, прикладыванием пропуска для печати на HP M8xx, а то и даже Ricoh Pro 8ххх. Как обычно, запасаемся скриптами, GPO и еще раз скриптами.

Количество серверов в нашей инфраструктуре уже перевалило за 800, хотя еще год назад их было около 500. Для работы с этим всем активно используются решения от Red Hat. Про FreeIPA — для организации и управления доступами для Linux-серверов — мы уже писали, сейчас же я хочу затронуть тему управления конфигурациями. Для этих целей у нас юзается Ansible, а с недавних пор к нему добавился AWX — представленное полгода назад решение для централизованного управления плейбуками, расписанием их запусков, управления инвентори, учетными данными для доступа к серверам, а также механизм callback'ов для запроса конфигураций со стороны сервера.

Из-за ряда вещей мы не сразу смогли интегрировать его для работы с нашим основным проектом War Robots, но полей для проверки AWX нашлось предостаточно. Во-первых, в компании ведутся разработки новых проектов, которым нужны dev/stage-окружения и, само собой, production-окружения в перспективе. А недавно к этому добавился еще и проект для внутренней аналитики, которому потребовался полностью новый кластер.

Итак, начнём!

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



Мы продолжаем цикл из 27 статей на основе его лекций:

01/02: «Понимание модели OSI» Часть 1 / Часть 2
03: «Понимание архитектуры Cisco»
04/05: «Основы коммутации или свитчей» Часть 1 / Часть 2
06: «Свитчи от Cisco»
07: «Область использования сетевых коммутаторов, ценность свитчей Cisco»
08/09: «Основы беспроводной локальной сети» Часть 1 / Часть 2
10: «Продукция в сфере беспроводных локальных сетей»
11: «Ценность беспроводных локальных сетей Cisco»
12: «Основы маршрутизации»
13: «Строение роутеров, платформы маршрутизации от Cisco»
14: «Ценность роутеров Cisco»
15/16: «Основы дата-центров» Часть 1 / Часть 2
17: «Оборудование для дата-центров»
18: «Ценность Cisco в дата-центрах»
19/20/21: «Основы телефонии» Часть 1 / Часть 2 / Часть 3
22: «Программные продукты для совместной работы от Cisco»
23: «Ценность продуктов для совместной работы от Cisco»
24: «Основы безопасности»
25: «Программные продукты Cisco для обеспечения безопасности»
26: «Ценность продуктов Cisco для обеспечения безопасности»
27: «Понимание архитектурных игр Cisco (обзор)»

И вот двадцать четвёртая из них.

Пора поговорить про удобную работу с логами, тем более что в Windows есть масса неочевидных инструментов для этого. Например, Log Parser, который порой просто незаменим.

В статье не будет про серьезные вещи вроде Splunk и ELK (Elasticsearch + Logstash + Kibana). Сфокусируемся на простом и бесплатном.

В финальной части нашей серии статей о работе с Git мы продолжим разговор о ветках, рассмотрим особенности работы с командой push и расскажем, что такое rebase. Первую и вторую статьи серии вы можете прочитать по ссылкам.

А вот и финальная третья часть нашей серии статей о центре сертификации на предприятии. Сегодня рассмотрим развертывание службы сертификатов на примере Windows Server 2016. Поговорим о подготовке контроллера домена, подготовке веб-сервера, установке корневого и издающего центров сертификации и об обновлении сертификатов. Заглядывайте под кат!

Мы продолжаем нашу серию статей о центре сертификации на предприятии. Сегодня поговорим о построении диаграммы открытого ключа, планировании имен центра сертификации, планировании списков отзыва сертификатов и еще нескольких моментах. Присоединяйтесь!

Привет, Хабр! Мы начинаем новую серию статей. Она будет посвящена развертыванию службы сертификатов на предприятии на базе Windows Server 2016 с практическими примерами. Сегодня обозначим вступительные моменты и поговорим о типовых схемах развёртывания иерархии PKI: двухуровневой и многоуровневой. Обо всем этом читайте под катом.

В сегодняшней статье я расскажу об уязвимостях сервера 1С в корпоративной сети.

Как показала практика, в инсталляциях с 1С все допускают одни и те же ошибки разной степени серьезности. Я не буду касаться очевидных вещей вроде установки обновлений, но пройдусь по специфике работы сервера приложений под Windows. Например, по возможности бесконтрольно манипулировать базами Microsoft SQL с помощью инструментов 1С.

Привет, хабрапользователь! Сегодня я попробую представить тебе очередную статью о докере. Зачем я это делаю, если таких статей уже множество? Ответов здесь несколько. Во-первых не все они описывают то, что мне самому бы очень пригодилось в самом начале моего пути изучения докера. Во-вторых хотелось бы дать людям к теории немного практики прямо по этой теории. Одна из немаловажных причин — уложить весь накопленный за этот недолгий период изучения докера опыт (я работаю с ним чуть более полугода) в какой-то сформированный формат, до конца разложив для себя все по-полочкам. Ну и в конце-концов излить душу, описывая некоторые грабли на которые я уже наступил (дать советы о них) и вилы, решение которых в докере просто не предусмотрено из коробки и о проблемах которых стоило бы задуматься на этапе когда вас распирает от острого желания перевести весь мир вокруг себя в контейнеры до осознавания что не для всех вещей эта технология годна.

Что мы будем рассматривать в данной статье?

В Части 0 (теоретической) я расскажу вам о контейнерах, что это и с чем едят
В Частях 1-5 будет теория и практическое задание, где мы напишем микросервис на python, работающий с очередью rabbitmq.
В Части 6 — послесловие

Всем доброго дня.

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

1) Предисловие

Вопрос необходимости резервного копирования в автоматическом режиме не подлежит сомнению ни у корифеев, ни у новичков. В статье рассмотрим резервное копирование средствами 1С (что имеет ряд преимуществ перед копированием средствами СУБД). При этом будут применены средства пакетного запуска платформы 1С, powershell и планировщик задач Windows.

Задачи обновления информационных давно автоматизированы, но только для типовых конфигураций, либо тех, что используют библиотеку стандартных подсистем. В моем случае мы работаем со старенькой Альфа-Авто редакции 4, которая распространяется на 12 серверов. Изменения вносятся примерно два раза в неделю, поэтому выгода от автоматизации налицо.

В обоих случаях мы имеем следующие исходные данные:

• Операционная система Windows Server (версии от 2008 до 2012);
• Клиент-серверный вариант платформы 1С 8.3 (с обязательно установленным компонентом COM-соединение).

Разумеется, у нас есть учетные данные ОС и 1С с административными правами.
Для обновления конфигурации так же понадобится ftp-сервер.

Прим. перев.: Автор статьи — Melvin Dave Vivas, возглавляющий команду разработчиков и SRE-инженеров в сингапурском банке, — делится своим опытом знакомства с поддержкой Kubernetes в платформе Docker.

Когда в октябре прошлого года на DockerCon 2017 технический директор Docker Inc Соломон Хайкс (Solomon Hykes) анонсировал родную поддержку Kubernetes, мне стало очень любопытно, как это будет работать.



Поэтому после анонса я решил проверить наличие этой поддержки в Edge-версии, о чём писал Michael Frills в блоге Docker. Но на тот момент её не оказалось. И вот, после нескольких месяцев ожиданий, она наконец-то появилась.

A forwarding entity always forwards packets in per-flow order to
zero, one or more of the forwarding entity’s own transmit interfaces
and never forwards a packet to the packet’s own receive interface.
Brian Petersen. Hardware Designed Network

Одно из удивительнейших достижений современности — это то, как, сидя в Норильске, человек может чатиться со своим другом в Таиланде, параллельно покупать билет на вечерний самолёт к нему, расплачиваясь банковской картой, в то время, как где-то в Штатах на виртуалочке его бот совершает сделки на бирже со скоростью, с которой его сын переключает вкладки, когда отец входит в комнату.

А через 10 минут он закажет такси через приложение на телефоне, и ему не придётся даже брать с собой в дорогу наличку.

В аэропорту он купит кофе, расплатившись часами, сделает видеозвонок дочери в Берлин, а потом запустит кинцо онлайн, чтобы скоротать час до посадки.

За это время тысячи MPLS-меток будут навешаны и сняты, миллионы обращений к различным таблицам произойдут, базовые станции сотовых сетей передадут гигабайты данных, миллиарды пакетов больших и малых в виде электронов и фотонов со скоростью света понесутся в ЦОДы по всему миру.

Это ли не электрическая магия?

В своём вояже к QoS, теме обещанной многократно, мы сделаем ещё один съезд. На этот раз обратимся к жизни пакета в оборудовании связи. Вскроем этот синий ящик и распотрошим его.


Кликабельно и увеличабельно.

Сегодня:

1. Коротко о судьбе и пути пакета
2. Плоскости (они же плейны): Forwarding/Data, Control, Management
3. Кто как и зачем обрабатывает трафик
4. Типы чипов: от CPU до ASIC'ов
5. Аппаратная архитектура сетевого устройства
6. Путешествие длиною в жизнь