По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Сегодня мы рассмотрим настройку времени на устройствах Cisco при помощи протокола NTP (Network Time Protocol). С токи зрения VoIP иметь правильное время на всех устройствах важно по нескольким причинам: Это позволяет IP-телефонам Cisco отображать пользователям правильную время и дату Это позволяет выставлять правильную дату и время Voicemail сообщениям Это позволяет указывать правильное время и дату в Call Detail Records (CDR) , который используется для отслеживания звонка в сети Это играет большую роль в функциях безопасности на всех устройствах Cisco Это позволяет указывать правильное время и дату в логах коммутаторов и маршрутизаторов Изначально когда устройство Cisco загружается, то у многих дефолтное время будет установлено на полдень 1 марта, 1993 года. Есть два способа сконфигурировать время: вручную ввести команду clock set из привелигерованного раздела EXEC или автоматически, используя Network Time Protocol (NTP). Устройства, получающие время по NTP всегда имеют более точное время, чем устройства, на которых время было установлено вручную. Так, например, все устройства в сети, использующие NTP, будут иметь одинаковое время. Точность часов определяется параметром stratum у NTP сервера. К серверу stratum 1 непосредственно подключены радио или атомные часы. Устройство, которое получает время от него, считается stratum 2. Устройство, получающее время от stratum 2 считается stratum 3 и так далее. В интернете можно найти много списков NTP серверов, например на сайте www.ntp.org После того как мы нашли желаемый сервер можно приступать к конфигурации, используя следующие команды. Router#conf t Router(config)#ntp server 64.209.210.20 Router(config)#clock timezone MSK 3 При помощи команды ntp server [ip_адрес] мы указываем к какому серверу мы будем подключаться для определения времени. По умолчанию на устройстве будет выставлена временная зона UTC (Universal Time Coordinated) . Чтобы настроить временную зону нужно ввести команду clock timezone [имя] [часы] и указать необходимый сдвиг во времени. В данном случае мы указали UTC+3. После конфигурации выполнить проверку можно командами show ntp associations и show ntp status. После того как мы настроили наше устройство для синхронизации с NTP сервером, мы можем использовать его для того, чтобы другие устройства в сети получали от него информацию о времени. Для этого используется команда ntp master [stratum number] . Например, введя команду ntp master 4, мы сможем отдавать информацию о времени со stratum 4 и остается только указать это устройство в качестве источника.
img
Подаренный компанией Google сообществу Opensource, Kubernetes теперь стал инструментом контейнерного хранения по выбору. Он может управлять и координировать не только среду выполнения докеров, но и среду контейнерного хранения объектов и Rkt. Типичный кластер Kubernetes обычно имеет главный узел и несколько рабочих узлов или Minions. Управление рабочими узлами осуществляется из главного узла, что обеспечивает управление кластером из центральной точки. Важно также отметить, что можно развернуть кластер с одним узлом Kubernetes, который обычно рекомендуется использовать для легких непроизводственных рабочих нагрузок. Для этого можно взять Minikube - инструмент, который управляет кластером K ubernetes с одним узлом в виртуальной машине. В этом руководстве мы рассмотрим многоузловую установку кластера Kubernetes в системе Linux CentOS 7. Это учебное пособие основано на командной строке и требует доступа к окну терминала. Требования Иметь несколько серверов под управлением Centos 7 (1 главный узел, 2 рабочих узла). Рекомендуется, чтобы главный узел содержал по крайней мере 2 ЦП, хотя это не является строгим требованием. Подключение к Интернету на всех узлах. Мы будем извлекать пакеты Kubernetes и докеров из хранилища. Кроме того, необходимо убедиться, что диспетчер пакетов yum установлен по умолчанию и может получать пакеты удаленно. Вам также потребуется доступ к учетной записи с правами sudo или root. В этом учебном пособии я буду использовать свою учетную запись root. Наш 3-узловой кластер будет выглядеть примерно так: Установка кластера Kubernetes на главном узле Для работы Kubernetes потребуется механизм контейнеризации. Для этой установки мы будем использовать docker, так как он самый популярный. На главном узле выполняются следующие шаги. Шаг 1: Подготовить имя узла, брандмауэр и SELinux На главном узле задайте имя хоста и, если у вас нет DNS-сервера, обновите файл /etc/hosts. # hostnamectl set-hostname master-node # cat <<EOF>> /etc/hosts 10.128.0.27 master-node 10.128.0.29 node-1 worker-node-1 10.128.0.30 node-2 worker-node-2 EOF Можно выполнить проверку связи с рабочим узлом 1 и рабочим узлом 2, чтобы убедиться в правильности работы обновленного файла хоста с помощью команды ping. # ping 10.128.0.29 # ping 10.128.0.30 Затем отключите SElinux и обновите правила брандмауэра. # setenforce 0 # sed -i --follow-symlinks 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/sysconfig/selinux # reboot Установите следующие правила брандмауэра для портов. Убедитесь, что каждая команда firewall-cmd возвращает результат. # firewall-cmd --permanent --add-port=6443/tcp # firewall-cmd --permanent --add-port=2379-2380/tcp # firewall-cmd --permanent --add-port=10250/tcp # firewall-cmd --permanent --add-port=10251/tcp # firewall-cmd --permanent --add-port=10252/tcp # firewall-cmd --permanent --add-port=10255/tcp # firewall-cmd –reload # modprobe br_netfilter # echo '1' > /proc/sys/net/bridge/bridge-nf-call-iptables Шаг 2: Настройка Kubernetes Repo Нужно будет вручную добавить хранилище Kubernetes, так как оно не установлено по умолчанию в CentOS 7. cat <<EOF > /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64 enabled=1 gpgcheck=1 repo_gpgcheck=1 gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg EOF Шаг 3: Установить Kubeadm и Docker После того, как пакет repo уже готов, вы можете продолжить и установить kubeadm и docker пакеты. # yum install kubeadm docker -y После успешного завершения установки включите и запустите обе службы. # systemctl enable kubelet # systemctl start kubelet # systemctl enable docker # systemctl start docker Шаг 4: Установка Kubernetes Master и настройка пользователя по умолчанию Теперь мы готовы инициализировать Kubernetes Master, но до этого нужно отключить swap, чтобы запустить команду kubeadm init. # swapoff –a Инициализация Kubernetes master - это полностью автоматизированный процесс, управляемый командой kubeadm init, которую необходимо выполнить. # kubeadm init Инициализация Kubernetes master Возможно, потребуется скопировать последнюю строку и сохранить ее в другом месте, поскольку нужно будет запустить ее на рабочих узлах. kubeadm join 10.128.0.27:6443 --token nu06lu.xrsux0ss0ixtnms5 --discovery-token-ca-cert-hash sha256:f996ea3564e6a07fdea2997a1cf8caeddafd6d4360d606dbc82314688425cd41 Совет: Иногда эта команда может жаловаться на переданные аргументы (args), поэтому отредактируйте ее, чтобы избежать ошибок. Таким образом, вы удалите символ , сопровождающий --token, и ваша последняя команда будет выглядеть следующим образом. kubeadm join 10.128.0.27:6443 --token nu06lu.xrsux0ss0ixtnms5 --discovery-token-ca-cert-hash sha256:f996ea3564e6a07fdea2997a1cf8caeddafd6d4360d606dbc82314688425cd41 После успешной инициализации Kubernetes необходимо разрешить пользователю начать использование кластера. В нашем случае мы хотим запустить эту установку от имени пользователя root, поэтому мы продолжим выполнение этих команд с этого же имени. Вы можете перейти на пользователя с поддержкой sudo, который вы предпочитаете, и запустить ниже с помощью sudo. Чтобы использовать root, выполните следующие действия: # mkdir -p $HOME/.kube # cp -i /etc/kubernetes/admin.conf $HOME/.kube/config # chown $(id -u):$(id -g) $HOME/.kube/config Чтобы быть пользователем с поддержкой sudo, выполните следующие действия: $ mkdir -p $HOME/.kube $ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config $ sudo chown $(id -u):$(id -g) $HOME/.kube/config Теперь проверьте, активирована ли команда kubectl. # kubectl get nodes На этом этапе также можно заметить, что главный узел имеет статус NotReady. Это связано с тем, что сеть модулей еще не развернута в кластере. Pod Network - это сеть наложения для кластера, которая развернута поверх текущей сети узла. Она предназначена для обеспечения возможности подключения через модуль. Шаг 5: Настройка сети модуля Применение сетевого кластера является очень гибким процессом в зависимости от потребностей пользователя и наличия множества доступных вариантов. Так как мы хотим сохранить нашу установку как можно проще, мы будем использовать плагин Weavenet, который не требует никакой конфигурации или дополнительного кода, и он предоставляет один IP-адрес на модуль, что отлично для нас. Для просмотра дополнительных параметров проверьте здесь. Эти команды будут важны для настройки сети модуля. # export kubever=$(kubectl version | base64 | tr -d ' ') # kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$kubever" Теперь, если вы проверите статус главного узла, он должен показать "Ready" # kubectl get nodes Далее мы добавим рабочие узлы в кластер. Настройка рабочих узлов для присоединения к кластеру Kubernetes Следующие шаги будут выполнены на рабочих узлах. Эти шаги должны выполняться на каждом рабочем узле при присоединении к кластеру Kubernetes. Шаг 1: Подготовить имя узла, брандмауэр и SELinux На рабочем узле-1 и рабочем узле-2 задайте имя, а если у вас нет DNS-сервера, то обновите основные и рабочие узлы в файле /etc/hosts. # hostnamectl set-hostname 'node-1' # cat <<EOF>> /etc/hosts 10.128.0.27 master-node 10.128.0.29 node-1 worker-node-1 10.128.0.30 node-2 worker-node-2 EOF Можно выполнить ping master-node для проверки правильности обновленного файла хоста. Затем отключите SElinux и обновите правила брандмауэра. # setenforce 0 # sed -i --follow-symlinks 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/sysconfig/selinux Установите следующие правила брандмауэра для портов. Убедитесь, что все команды firewall-cmd возвращаются успешно. # firewall-cmd --permanent --add-port=6783/tcp # firewall-cmd --permanent --add-port=10250/tcp # firewall-cmd --permanent --add-port=10255/tcp # firewall-cmd --permanent --add-port=30000-32767/tcp # firewall-cmd --reload # echo '1' > /proc/sys/net/bridge/bridge-nf-call-iptables Шаг 2: Настройка Kubernetes Repo Вам потребуется добавить хранилище Kubernetes вручную, так как оно не будет предварительно установлено на CentOS 7. cat <<EOF > /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64 enabled=1 gpgcheck=1 repo_gpgcheck=1 gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg EOF Шаг 3: Установить Kubeadm и Docker После того, как пакет repo уже готов, вы можете продолжить и установить kubeadm и docker пакеты. # yum install kubeadm docker -y Запустите и включите обе службы. # systemctl enable docker # systemctl start docker # systemctl enable kubelet # systemctl start kubelet Шаг 4: Присоединение рабочего узла к кластеру Кубернетов Теперь для присоединения к кластеру требуется маркер, созданный kubeadm init. Его можно скопировать и вставить в узлы 1 и 2, если он был скопирован в другом месте. # kubeadm join 10.128.0.27:6443 --token nu06lu.xrsux0ss0ixtnms5 --discovery-token-ca-cert-hash sha256:f996ea3564e6a07fdea2997a1cf8caeddafd6d4360d606dbc82314688425cd41 Как показано в последней строке, вернитесь к главному узлу и проверьте, присоединились ли рабочие узлы 1 и 2 к кластеру с помощью следующей команды. # kubectl get nodes Если все шаги выполнены успешно, на главном узле должны быть показаны узлы 1 и 2 в состоянии готовности. На этом этапе мы успешно завершили установку кластера Kubernetes на Centos 7 и успешно взяли два рабочих узла. Теперь можно начинать создавать модули и разворачивать службы.
img
Как и множество других инструментов для управления и автоматизации на рынке программного обеспечения, Ansible был изначально open – source проектом (с открытым исходным кодом), который предназначался для автоматизации настройки и деплоймента (развертывания) ПО в сетевых контурах компаний. Чего скрывать, продукт «стрельнул» - когда компания AnsibleWorks это поняла, начала активную монетизацию через коммерческую поддержку продукта для корпоративных заказчиков. /p> В настоящее время их продуктовая линейка состоит из двух направлений - Ansible и Ansible Tower, причем последний обладает полноценным интерфейсом управления (UI) и возможностью реализации дашбордов. Ansible - новые ребята в DevOps направлении, по сравнению, например, с Chef или Puppet, но успели круто зарекомендовать себя в сообществе профессионалов за простоту и скоуп возможностей. Его playbooks понятны и легко читаемы, даже без особых знаний. Так к чему это все? В «правильных руках», где присутствует полное понимание плюсов и минусов продукта Ansible может работать еще круче :) Поэтому, хотим рассказать про 5 лучших и 5 худших свойств Ansible. Playbooks в Ansible это файл в формате YAML, который содержит последовательность состояния ресурсов системы, задач, которые позволяет запустить то или состояние сервера. Что такое DevOps, что нужно знать и сколько получают DevOps - специалисты? 5 лучших качеств Ansible Легкость в изучении По правде говоря, это одно из самых крутых качеств Ansible – изучить его можно за один вечер и уже запускать веб – сервер из YAML, например. Ansible задачи запускаются последовательно, что сильно облегчает траблшутинг конфигураций. Например, можно сделать Playbook для Ansible, который позволит получить минимальный веб сервер примерно так: Создаем файл формата .yml и наполняем командами; Установить через yum apache; Запустить apache как сервис в операционной системе; Скопировать в корень веб – сервера html страничку с заглушкой («Мы готовим информацию по сайту, скоро здесь все будет, бла бла бла..»); Скорректировать iptables, открыв порты и сохранить конфигурацию; Не сложно, не правда ли? Написан на Python Я, как автор статьи, подметил следующее: если мы возьмем 10 программистов, вероятность, что кто-то из них знает Python гораздо выше, чем то, что кто – то из них знает Ruby. Именно это делает Ansible крутым – он написан на питоне в отличие от Ruby – based конкурентов. Так же отмечу, что Python библиотека, обычно, по умолчанию присутствует в любом Linux дистрибутиве, чего не сказать о Ruby. Продолжая экскурсию – Ansible поддерживает написание модулей на любом языке программирования. Единственное требование – формат ответа. Это должен быть JSON. Не нужно ставить клиента (агента) на машину Для управления узлами, Ansible обрабатывает все коммуникации между мастер – узлами и узлами – агентами по стандартному SSH, или через модуль Paramiko, который является частью Python SSH второй версии. Не нужно ставить агентское ПО на удаленные машины – только SSH подключение. Как следствие, упрощение обслуживания и траблшутинга. YAML плейбуки Как мы писали ранее, плейбуки в Ансибл невероятно просты и читаемы. Все DevOps инженеры, с которыми мы обсуждали его, освоили их за один вечер. Они даже проще чем JSON :) Портал Ansible Galaxy Портал, на котором вы наверняка найдете решение для своей задачи. Это объединение Ansible сообщества, где люди делятся наработками и решениями той или иной задачи. Знаете, это как ответ на мэйл.ру - чтобы вам не пришло реализовать на Ансибл, то как правило, кто – то эту задачу уже решил :). Тонны плейбуков, фреймворков, дистрибутивов и сопутствующего ПО. 5 худших качеств Ansible Настало время хорошенько пройтись по Ansible и выделить минусы продукта. Пожестим. Проблемы с интерфейсом (UI) Изначально Ansible разработан для работы с командной строкой. Первые наметки в сторону визуализации конфигурации Ансибл начались через AWX – графический интерфейс пользователя, который являлся первой попыткой упрощения конфигураций через интерфейсную составляющую. В последствии, AWX превратился в Anbile Tower, который дает возможность через GUI управлять Ansible, рисовать workflow и так далее. Несмотря на улучшение Tower перед AWX, он все равно позволяет делать только 85% рабочего функционала Ansible, который можно делать через командную строку. В добавок, конфигурации внесенный через интерфейс зачастую не синхронизируются с CLI – конфигами. Ansible Tower находится на стадии разработки и пока весьма сыроват. Нет работы с состоянием машин/процессов Если сравнивать с тем же Puppet, Ansible не имеет понятия «состояние» и, соответственно, не отслеживает его. Ансибл не смотрит на зависимости, а просто выполняет последовательный ряд задач/процессов. Для кого – то это нормально и удовлетворяет поставленным задачам, но есть и другие пользователи, у которых от такой работы, мягко говоря, «подгорает» :) Слабая поддержка совместимости с Windows С версии 1.7 Ansible умеет работать с Unix и Windows узлами, но надо признаться, работа с первыми реализована гораздо лучше. Взаимодействие с Windows машинами происходит через PowerShell, и, что важно, вам все равно потребуется Linux хост (управляющая тачка) для такой коммуникации. Ждем, когда Ansible разрабы разгребут бэклог по работе продукта с Windows. Поддержка крупного бизнеса Ansible Enterprise Tower и Premiun Tower имеют 8х5х4 и 24х7х2 SLA соответственно, но имеют меньше опыта поддержки крупняков, в сравнении, например, с Chef и Puppet. Новизна продукта Ansible находится на рынке меньше своих конкурентов и, само собой, баги будут всплывать. К тому же, комьюнити Ансибл только растет и развивается, в отличие от более крупных игроков, упомянутых в этой статье. Итоги Подведем черту: Ansible это просто, гибкий и мощный инструмент, для управления конфигами и автоматизацией. Ansible Tower имеет графический веб – интерфейс, REST API, с помощью которого вы можете интегрировать свой сторонние приложения и поддержку, которая только учится и осваивает азы сопровождения крупного энтерпрайза. Ansible – новинка, которая имеет своих ранних последователей, противников, сторонников. Сочетая в себе большое количество плюсов, он, конечно, имеет ряд недостатков или так сказать «ранних болезней», через которые уже прошли более крупные конкуренты. Но кто знает, что покажет нам Ansible завтра?
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59