По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Теперь вы знаете, как работают глобальные префиксы и подсети, а как насчет ID интерфейса? Мы еще не говорили о назначении IPv6-адресов нашим хостам. Назначение адресов хостам почти то же самое, что и для IPv4:
Адреса должны быть уникальными для каждого хост;
Вы не можете использовать префиксный адрес в качестве адреса хоста.
Ранее мы писали про основы работы протокола IPv6 (Internet Protocol version 6).
Вы можете настроить IPv6-адрес вручную вместе со шлюзом по умолчанию, DNS-сервером и т. д. или ваши хосты могут автоматически получить IPv6-адрес либо через DHCP, либо через что-то новое, называемое SLAAC (Stateless Address Autoconfiguration).
Вот пример IPv6 адресов, которые вы могли бы выбрать для топологии, которая показана выше:
Для интерфейсов роутера предлагаю использовать наименьшие числа, так как они легко запоминаются. В этом примере показан уникальный global unicast IPv6-адрес для каждого устройства.
Это все, что касается global unicast адресов, так же мы должны рассмотреть уникальные локальные одноадресные адреса.
Уникальные локальные адреса работают так же, как и частные адреса IPv4. Вы можете использовать эти адреса в своей собственной сети, если не собираетесь подключаться к Интернету или планируете использовать IPv6 NAT. Преимущество уникальных локальных адресов заключается в том, что вам не нужно регистрироваться в специализированном органе, чтобы получить дополнительные адреса.
Вы можете распознать эти адреса, потому что все они начинаются с FD в шестнадцатеричном формате. Есть еще несколько правил, которым вы должны следовать, если хотите использовать уникальные локальные адреса:
Убедитесь, что FD - это первые два шестнадцатеричных символ;
Вам нужно составить 40-битный глобальный ID, вы можете выбрать все, что вам нравится;
Добавьте 40-битный глобальный ID после "FD", чтобы создать 48-битный префикс;
Следующие 16 бит должны использоваться для подсетей
Это оставляет вам последние 64 бита для использования идентификатора интерфейса. Вот как выглядит уникальный локальный адрес:
Это дает нам уникальный локальный адрес, который мы можем использовать в наших собственных сетях. Подсети global unicast адресов или уникальных локальных адресов точно такие же, за исключением того, что на этот раз мы сами создаем префикс вместо того, чтобы провайдер назначил нам глобальный префикс. Глобальный ID может быть любым, что вам нравится, с 40 битами у вас будет 10 шестнадцатеричных символов для использования. Вы можете выбрать что-то вроде 00 0000 0001, поэтому, когда вы поставите перед ним "FD", у вас будет префикс FD00:0000:0001::/48. Вы можете удалить некоторые нули и сделать этот префикс короче, он будет выглядеть так: FD00:0:1:: / 48
Теперь вы можете добавить различные значения за префиксом, чтобы сделать уникальные подсети:
FD00:0:1:0000::/6;
FD00:0:1:0001::/6;
FD00:0:1:0002::/6;
FD00:0:1:0003::/6;
FD00:0:1:0004::/6;
FD00:0:1:0005::/6;
FD00:0:1:0006::/6;
FD00:0:1:0007::/6;
FD00:0:1:0008::/6;
FD00:0:1:0009::/6;
FD00:0:1:000A::/6;
FD00:0:1:000B::/6;
FD00:0:1:000C::/6;
FD00:0:1:000D::/6;
FD00:0:1:000E::/6;
FD00:0:1:000F::/6;
FD00:0:1:0010::/6;
FD00:0:1:0011::/6;
FD00:0:1:0012::/6;
FD00:0:1:0013::/6;
FD00:0:1:0014::/6;
И так далее.
Когда вы выполняете лабораторные работы, можно использовать простой глобальный ID. В конечном итоге вы получите короткий и простой в запоминании префикс. Для производственных сетей лучше использовать глобальный ID, чтобы он был действительно уникальным. Возможно, однажды вы захотите подключить свою сеть к другой сети, или, возможно, вам придется объединить сети. Когда обе сети имеют один и тот же глобальный идентификатор, вам придется изменить IPv6-адрес для объединённой сети. В случае, если глобальные идентификаторы отличаются, Вы можете просто объединить их без каких-либо проблем.
Настройка на маршрутизаторе
В оставшейся части этой статьи мы рассмотрим, как можно настроить IPv6 на наших роутерах. Если вы хотите настроить IPv6 адрес на роутере у вас есть два варианта:
Вручную настроить 128-битный IPv6-адрес;
Использовать EUI-64;
Сначала я покажу вам, как вручную настроить IPv6-адрес, а затем объясню, что такое EUI-64. Вот что необходимо выполнить:
OFF1(config)#interface fastEthernet 0/0
OFF1(config-if)#ipv6 address 2001:1234:5678:abcd::1/64
Вам нужно использовать команду ipv6 address, а затем вы можете ввести адрес IPv6. Префикс, который я использую, - это 2001:1234:5678:abcd, и этот роутер будет иметь в качестве своего адреса "хоста" "1". Если хотите Вы также можете ввести полный IPv6-адрес:
OFF1(config)#interface fastEthernet 0/0
OFF1(config-if)#ipv6 address 2001:1234:5678:abcd:0000:0000:0000:0001/64
Эта команда будет иметь точно такой же результат, что и команда, введенная ранее. Мы можем проверить подсеть и IPv6-адрес следующим образом:
OFF1#show ipv6 interface fa0/0
FastEthernet0/0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::C000:18FF:FE5C:0
No Virtual link-local address(es):
Global unicast address(es):
2001:1234:5678:ABCD::1, subnet is 2001:1234:5678:ABCD::/64
Данный вывод информации отображает global unicast адрес и нашу подсеть. Есть еще одна важная вещь, когда мы настраиваем IPv6 на роутере. По умолчанию роутер не будет пересылать никакие пакеты IPv6 и не будет создавать таблицу маршрутизации. Чтобы включить "обработку" пакетов IPv6, нам нужно включить его:
OFF1(config)#ipv6 unicast-routing
Большинство команд "ip" будут работать, просто попробуйте "ipv6" вместо этого и посмотрите, что он делает:
OFF1#show ipv6 interface brief
FastEthernet0/0 [up/up]
FE80::C000:18FF:FE5C:0
2001:1234:5678:ABCD::1
OFF1#show ipv6 route connected
IPv6 Routing Table - 3 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
U - Per-user Static route, M - MIPv6
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
D - EIGRP, EX - EIGRP external
C 2001:1234:5678:ABCD::/64 [0/0]
via ::, FastEthernet0/0
Теперь вы знаете, как настроить IPv6-адрес вручную и как его проверить. После, почитайте о том, как настроить IPv6 с EUI-64 на Cisco.
Docker и Kubernetes - два ведущих инструмента, используемых в индустрии облачных вычислений. В то время как Docker - это компьютерное приложение, использующее концепцию контейнеризации, а Kubernetes - это система оркестровки контейнеров.
Как правило, Docker и Kubernetes используются совместно друг с другом. Тем не менее, сравнение Kubernetes и Docker является чрезвычайно популярной темой в сообществе облачных вычислений.
Прежде чем сравнивать две наиболее важные технологии облачных вычислений, давайте сначала кратко расскажем о каждой из них.
Kubernetes
Впервые выпущенный в июне 2014 года, Kubernetes был изначально разработан Google. За дальнейшую разработку и обслуживание системы оркестровки контейнеров с открытым исходным кодом отвечает Cloud Native Computing Foundation.
Согласно официальному сайту, Kubernetes является «системой с открытым исходным кодом для автоматизации развертывания, масштабирования и управления контейнеризованными приложениями».
Используя технологию контейнеризации, Kubernetes позволяет запускать контейнеры на нескольких вычислительных узлах, которые могут быть простыми серверами или виртуальными машинами. Перед использованием Kubernetes нужно перепроверить несколько вещей. Одним из них является обеспечение того, чтобы все участвующие вычислительные узлы были надежно связаны друг с другом.
Docker
Разработанная Docker, Inc., Docker была впервые выпущена в марте 2013 года. Это компьютерная программа, способная выполнять виртуализацию на уровне операционной системы, широко известную как контейнерная упаковка.
Docker можно рассматривать в двух разных сторон. С первого взгляда контейнеры Docker - это действительно легкие виртуальные машины, а со второй точки зрения Docker - это платформа для упаковки и доставки программного обеспечения.
Последний аспект в первую очередь ответственен за огромную популярность технологии контейнеризации Docker и ее широкое распространение в индустрии облачных вычислений.
Можно ли сравнивать Docker и Kubernetes?
Сравнивать Docker с Kubernetes - все равно что сравнивать Солнце с Луной. Конечно, оба небесных тела, но сравнение между ними не звучит правильно! Это потому, что, хотя оба сияют, один - звезда, а другой - естественный спутник.
Хотя Docker может работать без Kubernetes, а Kubernetes может функционировать в полной мере без Docker, использование обоих в совместной работе улучшает функциональность друг друга. Docker может быть установлен на компьютере для запуска контейнерных приложений. Подход контейнеризации означает запуск приложений в операционной системе таким образом, чтобы они были изолированы от остальной части системы. Приложение будет чувствовать, что оно имеет свою собственную выделенную ОС.
Несколько приложений могут работать в одной ОС, как если бы у каждого из них был свой экземпляр операционной системы. Каждое приложение находится внутри контейнера. Docker позволяет создавать, управлять и запускать контейнеры в одной операционной системе.
Теперь, когда у вас установлен Docker на нескольких хостах, то есть на операционных системах, вы можете воспользоваться Kubernetes. В таком случае мы называем эти хосты узлами или узлами Docker, которые могут быть серверами с открытым исходным кодом или виртуальными машинами. Прелесть использования Kubernetes с Docker заключается в том, что он помогает автоматизировать балансировку нагрузки контейнера, создание сетей, выделение ресурсов, масштабирование и безопасность на всех хостах Docker с помощью отдельной панели мониторинга или интерфейса командной строки.
Повышение масштабируемости приложений и повышение надежности инфраструктуры - две лучшие причины выбора нескольких узлов. Коллекция узлов, управляемых отдельным экземпляром Kubernetes, называется кластером Kubernetes.
Kubernetes vs Docker
Docker Swarm, про настройку которого можно прочитать тут - это платформа оркестрации контейнеров с открытым исходным кодом. Это собственный механизм кластеризации для Docker, и поэтому он использует ту же командную строку, что и Docker. Ниже приведены различные важные различия между Swarm и Kubernetes.
Развертывание приложений
Приложение развертывается в Kubernetes с использованием комбинации модулей и служб (или микросервисов). В Docker Swarm развертывание приложения происходит просто в виде микросервисов или сервисов в кластере Swarm.
Docker Swarm поставляется с Docker Compose, который помогает в установке приложения. Для идентификации нескольких контейнеров в Docker Swarm есть файлы YAML (YAML Ain’t Markup Language).
Настройка контейнера
Хотя Docker Swarm API не поддерживает все команды Docker, он предлагает почти все лучшие функциональные возможности Docker.
Итак, Docker Swarm поддерживает большинство инструментов, доступных для Docker. Однако, если Docker API не способен выполнять некоторые необходимые операции, не существует простого обходного пути для их использования в Docker Swarm.
Как и Docker Swarm, Kubernetes имеет свою собственную версию API, определения клиентов и YAML. Тем не менее, они отличаются от их коллег Docker.
Следовательно, нет возможности использовать Docker CLI или Docker Compose для определения контейнеров в Kubernetes. В случаях, когда необходимо переключить платформу, команды и определения YAML необходимо переписать.
Балансировка нагрузки
Как правило, Ingress используется для балансировки нагрузки в Kubernetes. Тем не менее, есть и другой способ, в котором модуль в Kubernetes выставляется через сервис и его можно использовать в качестве балансировщика нагрузки в кластере, к которому он принадлежит.
Docker Swarm имеет DNS-элемент, который можно использовать для распределения входящих запросов по определенному имени службы. Для балансировки нагрузки службы могут быть назначены автоматически или настроены для работы на указанных пользователем портах.
Сеть
Kubernetes использует плоскую сетевую модель. Таким образом, все модули могут взаимодействовать друг с другом. Как будет происходить взаимодействие между модулями, определяется сетевыми политиками. Обычно модель плоской сети реализована в виде наложения.
Модель плоской сети в Kubernetes требует две CIDR (Classless Inter-Domain Routing): один для сервисов, а другой - от которого модули получают IP-адрес.
В Docker Swarm узел, присоединяющийся к кластеру Swarm, отвечает за генерацию оверлейной сети для сервисов, охватывающей каждый хост в кластере, и сети мостов Docker только для хостов для контейнеров.
Docker Swarm дает пользователям возможность шифровать трафик контейнерных данных при создании оверлейной сети.
Масштабируемость
Kubernetes - это комплексная структура для распределенных систем. Поскольку он предлагает унифицированный набор API и надежные гарантии состояния кластера, Kubernetes является сложной системой. Эти способности отвечают за замедление развертывания и масштабирования контейнера.
По сравнению с Kubernetes, Docker Swarm может развертывать контейнеры на гораздо более высокой скорости. Следовательно, это позволяет быстрее реагировать на масштабирование системы в соответствии с требованиями.
Синергия между Docker и Kubernetes
Kubernetes способен работать в тандеме с любой технологией контейнеризации. RKT и Docker являются двумя наиболее популярными опциями для механизма оркестровки контейнеров с открытым исходным кодом. Однако последний предпочтительнее, чем первый.
Из-за большего предпочтения использования Docker с Kubernetes было приложено много усилий для совершенствования сотрудничества между этими двумя технологиями.
Хотя Docker имеет свой собственный механизм оркестровки контейнеров в форме Docker Swarm, склонность к использованию Kubernetes с Docker нельзя не заметить. Это видно из того факта, что Docker for Desktop поставляется с собственным дистрибутивом Kubernetes.
Следовательно, совершенно очевидно, что обе технологии, Docker и Kubernetes, объединили свои усилия и также извлекли большую пользу из этого сотрудничества.
Жизнь системного администратора не проста. Поддержка систем, безопасность сетевого контура, решение проблем - уследить за всем сложно. Пользовательские пароли – важный нюанс и их, безусловно, нужно менять с определенной периодичностью.
В статье расскажем, как автоматически заставлять пользователей Linux сменить их пароли.
Срок действия паролей
Чтобы получить информацию о пользовательских паролях и о дате их окончания введите команду:
chage -l
Будет выведена следующая информация:
Когда пароль был последний раз изменен;
Дата окончания действия пароля;
Сколько дней осталось до окончания действия пароля;
Когда учетная запись пользователя будет закончена (можно, пожалуйста, далее мы будем говорить «заэкспайрится»?)
Минимальное количество дней между итерацией смены пароля;
Максимальное количество дней между итерацией смены пароля;
Заставляем пользователя менять пароль каждые 90 дней
Следующей командой вы можете поставить жесткое правило смены паролей:
sudo chage -M 90
Команду можно выполнить от root пользователя или от юзера с sudo правами. Проверить, что настройка установлена корректно, можно с помощью команды chage -l
Срок действия учетной записи
Представьте, у вас есть два юзера: Иван и Петр. И доступ им нужно организовать на 2 дня, с момента сегодняшней даты (сегодня echo rus_date("j F");). Получается, создаем им пользователей:
sudo adduser ivan
sudo adduser petr
Создаем пароли для них:
sudo passwd ivan
sudo passwd petr
Как мы уже сказали, Иван и Петр уезжают через 2 дня. Соответственно, делаем для них следующую конфигурацию:
sudo chage -E echo date("Y-m-d", strtotime("+2 days")); ivan
sudo chage -E echo date("Y-m-d", strtotime("+2 days")); petr
Если вы запустите команду chage -l , то увидите актуальную дату жизни аккаунта. Как только аккаунты Ивана и Петра заэкспайрятся, их можно будет удалить командой:
sudo chage -E -1 ivan
sudo chage -E -1 petr
Сколько времени на смену пароля?
Пароль Геннадия заэкспайрился (истек срок годности) в воскресение. Мы дадим Гене 5 дней, чтобы он зашел в свою учетную запись и сменил пароль. Если он этого не сделает, аккаунт будет заблокирован. Сделать это можно вот так:
sudo chage -I 5 gennady
Ну, а если Геннадий так и не сменит пароль и учетная запись заблокируется, удалить ее можно вот так:
sudo chage -I -1 gennady
Предупреждения для пользователей
Вы – адекватный человек. И наверняка хотите, чтобы ваши юзеры были уведомлены о смене пароля заранее. Например, чтобы Геннадий узнал, что через 7 дней истекает срок годности его пароля, дайте следующую команду:
sudo chage -W 7 gennady
Защищаемся от частой смены паролей
Вдруг в вашем штате завелся очень взволнованный безопасностью сотрудник, который меняет пароли каждый день? Такое. Чтобы сделать минимальное количество дней между сменой паролей в две недели (14 дней), можно указать следующую команду:
sudo chage -m 14 sergey
Сделали большой лимит и передумали? Не проблема – удалить ограничение в днях можно вот так:
sudo chage -m 0 sergey