One place for hosting & domains

      помощью

      Настройка бинарных файлов в Go с помощью тегов сборки


      Введение

      В Go тег сборки, или ограничение сборки, — это идентификатор, добавляемый в кусок кода, который определяет, когда файл должен быть включен в пакет в процессе сборки. Это позволяет создавать различные версии вашего приложения Go из одного исходного кода и переключаться между ними в быстрой и организованной манере. Многие разработчики используют теги сборки для упрощения рабочего процесса при сборке кросс-платформенных приложений, например, программ, которые требуют изменений кода для учета различий между разными операционными системами. Теги сборки также используются для тестирования интеграции, позволяя вам быстро переключаться между интегрированным кодом и кодом со службой mock или stub, а также для разделения уровней наборов функций внутри приложения.

      Давайте рассмотрим проблему разделения наборов клиентских функций в качестве примера. При написании некоторых приложений вы можете захотеть контролировать, какие функции включать в бинарный файл, например, при работе с приложением, которое имеет бесплатный, профессиональный и корпоративный уровни. Если пользователь повышает уровень подписки в этих приложениях, все больше функций становятся доступными. Чтобы решить эту проблему, вы можете поддерживать отдельные проекты и пытаться держать их в синхронизированном состоянии через использование оператора import. Хотя этот подход может сработать, со временем он вызовет все больше затруднений и ошибок. Альтернативным способом может быть использование тегов сборки.

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

      Предварительные требования

      Для выполнения примера из этой статьи вам потребуется следующее:

      Сборка бесплатной версии

      Давайте начнем со сборки бесплатной версии приложения, поскольку она будет использоваться по умолчанию при запуске go build без каких-либо тегов сборки. Позднее мы будем использовать теги сборки, чтобы избирательно добавлять другие части нашей программы.

      В директории src создайте папку с именем вашего приложения. В этом обучающем руководстве мы будем использовать app:

      Перейдите в эту папку:

      Затем создайте новый текстовый файл в текстовом редакторе по вашему выбору с именем main.go:

      Теперь мы определим бесплатную версию приложения. Добавьте следующее содержимое в main.go:

      main.go

      package main
      
      import "fmt"
      
      var features = []string{
        "Free Feature #1",
        "Free Feature #2",
      }
      
      func main() {
        for _, f := range features {
          fmt.Println(">", f)
        }
      }
      

      В этом файле мы создали программу, которая объявляет срез с именем features, который хранит две строки, представляющие собой функции бесплатной версии приложения. Функция main() в приложении использует цикл for для прохождения по срезу features и вывода всех доступных функций на экране.

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

      Выполните сборку и запустите программу:

      Вывод должен выглядеть следующим образом:

      Output

      > Free Feature #1 > Free Feature #2

      Программа вывела на экран две наши бесплатные функции, которые входят в бесплатную версию нашего приложения.

      Итак, сейчас у вас есть приложение с базовым набором функций. Далее вы узнаете, как добавить дополнительные функции в приложение во время сборки.

      Добавление профессиональных функций с помощью команды go build

      До этого мы избегали внесения изменений в main.go, симулируя стандартную рабочую среду, в которой код должен добавляться без изменений и возможного нарушения основного кода. Поскольку мы не можем изменять файл main.go, нам нужно будет использовать другой механизм для введения нового функционала в срез features с помощью тегов сборки.

      Давайте создадим новый файл pro.go, который будет использовать функцию init() для добавления дополнительных функций в срез features:

      После открытия файла в редакторе добавьте следующие строки:

      pro.go

      package main
      
      func init() {
        features = append(features,
          "Pro Feature #1",
          "Pro Feature #2",
        )
      }
      

      В этом коде мы использовали init() для запуска кода перед функцией main() нашего приложения, а затем append() для добавления профессиональных функций в срез features. Сохраните и закройте файл.

      Скомпилируйте и запустите приложение с помощью команды go build:

      Поскольку в нашей текущей директории есть два файла (pro.go и main.go), go build будет создавать бинарный файл для обоих из них. Запустите этот бинарный файл:

      В результате мы получим следующий набор функций:

      Output

      > Free Feature #1 > Free Feature #2 > Pro Feature #1 > Pro Feature #2

      Теперь приложение включает как профессиональные, так и бесплатные функции. Однако это нежелательно, поскольку различия между версиями отсутствуют, а бесплатная версия включает функции, которые должны быть доступны только в профессиональной версии. Чтобы исправить это, вы можете добавить код для управления разными слоями приложения, либо вы можете использовать теги сборки, чтобы сообщить цепочке инструментов Go, какие файлы .go нужно использовать для сборки, а какие игнорировать. Давайте добавим теги сборки в следующем шаге.

      Добавление тегов сборки

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

      Давайте начнем с изучения того, как выглядит тег сборки:

      // +build tag_name
      

      Добавив следующую строку кода в качестве первой строки вашего пакета и заменив tag_name на имя вашего тега сборки, вы пометите этот пакет в качестве кода, который может быть выборочно включен в конечный бинарный файл. Давайте посмотрим это в действии, добавив тег сборки в файл pro.go, чтобы указать команде go build игнорировать его, если тег не указан. Откройте файл в своем текстовом редакторе:

      А затем добавьте следующую выделенную строку:

      pro.go

      // +build pro
      
      package main
      
      func init() {
        features = append(features,
          "Pro Feature #1",
          "Pro Feature #2",
        )
      }
      

      В верхней части файла pro.go мы добавили //+build pro с чистой новой строкой. Эта последующая строка должна присутствовать обязательно, иначе Go будет интерпретировать это содержимое как комментарий. Объявления тега сборки должны находиться в самой верхней части файла .go. Ничего, даже комментарии, не может быть выше тегов сборки.

      Объявление +build указывает команде go build, что это не комментарий, а тег сборки. Вторая часть — это тег pro. Добавив этот тег в верхней части файла pro.go, команда go build будет включать только файл pro.go только при наличии тега pro.

      Скомпилируйте и снова запустите приложение:

      Вывод должен выглядеть следующим образом:

      Output

      > Free Feature #1 > Free Feature #2

      Поскольку файл pro.go требует наличия тега pro, файл будет игнорироваться, а приложение будет компилироваться без этого файла.

      При запуске команды go build мы можем использовать флаг -tags для условного включения кода в скомпилированный источник, добавив тег как аргумент. Давайте сделаем это для тега pro:

      В результате вы получите следующий вывод:

      Output

      > Free Feature #1 > Free Feature #2 > Pro Feature #1 > Pro Feature #2

      Теперь мы получим только дополнительные функции, когда будем выполнять сборку приложения, используя тег сборки pro.

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

      Булева логика для тегов сборки

      Когда в пакете Go есть несколько тегов сборки, теги взаимодействуют друг с другом с помощью булевой логики. Чтобы продемонстрировать это, мы добавим корпоративный уровень вашего приложения, используя тег pro и тег enterprise.

      Чтобы создать бинарный файл для корпоративной версии, нам потребуется включить функции по умолчанию, функции профессионального уровня и новый набор функций для корпоративного уровня. Сначала откройте редактор и создайте новый файл enterprise.go, который будет добавлять новые функции корпоративного уровня:

      Содержимое файла enterprise.go будет выглядеть почти так же, как и в pro.go, но будет содержать новые функции. Добавьте в файл следующие строки:

      enterprise.go

      package main
      
      func init() {
        features = append(features,
          "Enterprise Feature #1",
          "Enterprise Feature #2",
        )
      }
      

      Сохраните и закройте файл.

      В настоящее время в файле enterprise.go нет тегов сборки, а как вы узнали при добавлении pro.go, это означает, что эти функции будут добавляться в бесплатную версию при исполнении go.build. Для pro.go вы добавили //+build pro и новую строку сверху файла, чтобы указать go build, что данный файл следует включать только при использовании -tags pro. В этой ситуации вам потребуется только один тег сборки для достижения цели. Однако при добавлении новых корпоративных функций у вас должны быть в наличии функции профессионального уровня.

      Давайте добавим поддержку тега сборки pro в файл enterprise.go. Откройте этот файл в текстовом редакторе:

      Далее добавьте тег сборки перед основным объявлением пакета main и обязательно добавьте новую строку после тега сборки:

      enterprise.go

      // +build pro
      
      package main
      
      func init() {
        features = append(features,
          "Enterprise Feature #1",
          "Enterprise Feature #2",
        )
      }
      

      Сохраните и закройте файл.

      Скомпилируйте и запустите приложение без каких-либо тегов:

      Вывод должен выглядеть следующим образом:

      Output

      > Free Feature #1 > Free Feature #2

      Функции корпоративной версии больше не отображаются в бесплатной версии. Теперь мы добавим тег сборки pro и выполним сборку и запуск приложения еще раз:

      Вывод должен выглядеть следующим образом:

      Output

      > Free Feature #1 > Free Feature #2 > Enterprise Feature #1 > Enterprise Feature #2 > Pro Feature #1 > Pro Feature #2

      Это все еще не совсем то, что нам нужно: корпоративные функции отображаются при попытке сборки профессиональной версии. Чтобы устранить эту проблему, нам потребуется другой тег сборки. В отличие от тега pro, нам нужно убедиться, что функции профессиональной и корпоративной версий доступны.

      Система сборки Go позволяет решить эту ситуацию посредством использования базовой булевой логики в системе тегов сборки.

      Давайте снова откроем файл enterprise.go​​​:

      Добавьте другой тег сборки, enterprise, в той же строке, что и тег pro:

      enterprise.go

      // +build pro enterprise
      
      package main
      
      func init() {
        features = append(features,
          "Enterprise Feature #1",
          "Enterprise Feature #2",
        )
      }
      

      Сохраните и закройте файл.

      Теперь мы скомпилируем и запустим приложение с новым тегом сборки enterprise.

      • go build -tags enterprise
      • ./app

      В результате вы получите следующий вывод:

      Output

      > Free Feature #1 > Free Feature #2 > Enterprise Feature #1 > Enterprise Feature #2

      Теперь мы потеряли функции профессиональной версии. Это объясняется тем, что при вводе нескольких тегов сборки в одной строке файла .go команда go build интерпретирует их, используя логику OR. После добавления строки //+build pro enterprise файл enterprise.go будет использоваться при сборке, только если любой из тегов сборки pro или enterprise будет присутствовать. Нам нужно корректно настроить теги сборки, чтобы требовать наличие обоих тегов и использовать логику AND.

      Вместо того, чтобы помещать оба тега в одной строке, если мы разместим их в отдельных строках, команда go build будет толковать эти теги, используя логику AND.

      Откройте файл enterprise.go еще раз и поместите теги сборки в разных строках.

      enterprise.go

      // +build pro
      // +build enterprise
      
      package main
      
      func init() {
        features = append(features,
          "Enterprise Feature #1",
          "Enterprise Feature #2",
        )
      }
      

      Теперь мы скомпилируем и запустим приложение с новым тегом сборки enterprise.

      • go build -tags enterprise
      • ./app

      Вывод должен выглядеть следующим образом:

      Output

      > Free Feature #1 > Free Feature #2

      И все равно это еще не все: поскольку оператор AND требует, чтобы оба элемента имели значение true, мы должны использовать оба тега сборки, как pro, так и enterprise.

      Давайте попробуем еще раз:

      • go build -tags "enterprise pro"
      • ./app

      Вывод должен выглядеть следующим образом:

      Output

      > Free Feature #1 > Free Feature #2 > Enterprise Feature #1 > Enterprise Feature #2 > Pro Feature #1 > Pro Feature #2

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

      В данном примере мы использовали новый тег //+build для обозначения логики AND, но есть альтернативные способы использования булевой логики с помощью тегов сборки. В данной таблице приведены примеры других синтаксических форматов для тегов сборки наряду с их эквивалентом в булевой логике:

      Синтаксис тега сборки Пример тега сборки Логический оператор
      Разделенные пробелами элементы // +build pro enterprise pro OR enterprise
      Разделенные запятой элементы // +build pro,enterprise pro AND enterprise
      Элементы с восклицательным знаком // +build ! pro NOT pro

      Заключение

      В этом обучающем руководстве вы использовали теги сборки для контроля того, какая часть кода будет компилироваться в бинарном файле. Сначала вы объявили теги сборки и использовали их с помощью команды go build, а затем сочетали несколько тегов с помощью булевой логики. Затем вы создали программу, представляющую различные наборы функций для бесплатной, профессиональной и корпоративной версий, для демонстрации уровня контроля, который теги сборки могут предоставить для вашего проекта.

      Если вы хотите узнать больше о тегах сборки, посмотрите документацию Golang по этой теме или продолжите изучение нашей серии статей о программировании на языке Go.



      Source link

      Начало работы с программно-конфигурируемой сетью и создание VPN с помощью ZeroTier One


      Введение

      Сегодня все больше и больше проектов разработки программного обеспечения реализуются командами, участники которых работают вместе из разных географических мест. Хотя у такого рабочего процесса есть много видимых преимуществ, существуют ситуации, когда таким командам может потребоваться соединить свои компьютеры через Интернет и рассматривать их так, будто они находятся в одной комнате. Например, вы можете заниматься тестированием распределенных систем, например Kubernetes, и созданием мультисервисных приложений. Иногда можно повысить продуктивность, если вы можете рассматривать компьютеры так, будто они находятся рядом с друг другом, поскольку вам не нужно будет рисковать тем, что ваши незавершенные службы попадут в Интернет. Эта парадигма может быть реализована через программно-конфигурируемую сеть (Software-Defined Networking, SDN) — сравнительно новую технологию, которая предоставляет динамическую сетевую систему, чье существование полностью опирается на программное обеспечение.

      ZeroTier One — это приложение с открытым исходным кодом, использующее некоторые из последних разработок в SDN, которое позволяет пользователям создавать защищенные, управляемые сети и рассматривать связанные устройства так, будто они находятся в одном физическом месте. ZeroTier предоставляет клиентам веб-консоль для управления сетью и программным обеспечением на конечных устройствах. Данный инструмент использует пиринговую технологию, а это значит, что, в отличие от традиционных VPN-решений, в процессе коммуникации не используется центральный сервер или маршрутизатор, а сообщения пересылаются напрямую из хоста к хосту. Результатом этого является высокая эффективность и минимальное время задержки. Среди других преимуществ следует отметить простоту процесса развертывания и конфигурации ZeroTier, удобство поддержки и возможность централизованной регистрации и управления авторизованными узлами через веб-консоль.

      Следуя указаниям данного руководства, вы сможете создать подключение клиента и сервера через простую сеть с двухточечным соединением. Так как программно-конфигурируемая сеть не использует традиционную схему клиент/сервер, нет необходимости в установке и настройке центрального сервера VPN. Это упрощает развертывание инструмента и добавление дополнительных узлов. После установки подключения у вас появится возможность использовать VPN-возможности ZeroTier с помощью ряда полезных функций Linux, чтобы разрешить трафику покидать вашу сеть ZeroTier через ваш сервер и дать клиенту указания по отправке своего трафика в этом направлении.

      Предварительные требования

      Прежде чем переходить к выполнению данного руководства, вам потребуются следующие ресурсы:

      • Сервер на базе Ubuntu 16.04. На этом сервере вам также потребуется пользователь без прав root с привилегиями sudo, которого можно настроить с помощью нашего руководства по начальной настройке сервера Ubuntu 16.04.

      • Учетная запись в ZeroTier One, которую вы можете создать, посетив My ZeroTier. Для настоящего руководства вы можете использовать бесплатную версию данного сервиса, которая не потребует расходов или обязательств.

      • Локальный компьютер для подключения к SDN в качестве клиента. В примерах в данном руководстве и сервер, и локальный компьютер работают под управлением Ubuntu Linux, но любую операционную систему, перечисленную в списке на странице загрузки ZeroTier, можно использовать для клиента.

      После выполнения этих предварительных требований вы можете начать настройку программно-конфигурируемой сети для вашего сервера и локального компьютера.

      Шаг 1 — Создание программно-конфигурируемой сети с помощью ZeroTier One

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

      Выполните вход в учетную запись ZeroTier, нажмите Networks (Сети) в верхней части экрана, а затем нажмите Create (Создать). Появится название автоматически сгенерированной сети. Нажмите на нее, чтобы просмотреть экран конфигурации вашей сети. Запишите Network ID​​​​​ (Идентификатор сети), выделенный желтым цветом, поскольку он потребуется вам позднее.

      Если вы захотите изменить имя сети на что-то более информативное, измените имя в левой части экрана. Вы можете добавить описание, если хотите. Любые изменения, которые вы вносите, сохраняются и применяются автоматически.

      Затем выберите адресное пространство IPv4, в котором будет работать SDN. С правой стороны экрана в области под названием IPv4 Auto-Assign (Автоматическое присвоение IPv4), выберите диапазон адресов, в котором будут находиться узлы. Для целей данного руководства можно использовать любое адресное пространство, но важно поставить галочку в поле Auto-Assign from Range (Автоматическая привязка из адресного пространства).

      Убедитесь, что для параметра Access Control (Контроль доступа) слева установлено значение Certificate (Private Network) (Сертификат (Частная сеть)). Это гарантирует, что только одобренные компьютеры смогут подключиться к сети, а не каждый, кто будет знать ваш идентификатор сети!

      После завершения настройки ваши параметры должны выглядеть примерно следующим образом:

      Конфигурация настроек ZeroTier

      К данному моменту вы успешно создали фундамент программно-конфигурируемой сети ZeroTier. Далее вам нужно будет установить программное обеспечение ZeroTier на сервер и клиентские компьютеры, чтобы они могли подключиться к вашей SDN.

      Шаг 2 — Установка клиента ZeroTier One на сервер и локальный компьютер

      Поскольку ZeroTier One является относительно недавно разработанным программным обеспечением, он еще не включен в основные репозитории программного обеспечения Ubuntu. По этой причине ZeroTier предоставляет скрипт установки, который мы будем использовать для установки программного обеспечения. Эта команда является скриптом с подписью GPG, что означает, что код, который вы загружаете, будет проверяться при публикации ZeroTier. Скрипт имеет четыре основные части, а ниже представлено подробное описание каждой из них:

      • curl -s 'https://pgp.mit.edu/pks/lookup?op=get&search=0x1657198823E52A61'​​​ — данная часть импортирует публичный ключ ZeroTier из MIT.
      • gpg --import — данная часть команды добавляет публичный ключ ZeroTier в локальную цепочку ключей полномочий, необходимых для проверки пакетов, которые вы пытаетесь установить. Следующая часть команды будет выполняться только при успешном завершении импорта GPG.
      • if z=$(curl -s 'https://install.zerotier.com/' | gpg); then echo "$z" — в этой части происходит несколько вещей, но ее можно перевести следующим образом: “если скрипт установки с криптографической подписью, загружаемый с ZeroTier.com, передается через GPG и не отклоняется как неподписанный ZeroTier, необходимо вставить эту информацию на экран”.
      • sudo bash; fi — данная часть использует прошедший валидацию скрипт установщика и выполняет его перед окончанием процесса.

      Предупреждение: никогда не загружайте что-либо из Интернета и не добавляйте это в другую программу, если вы не уверены в надежности источника. По желанию вы можете проверить программное обеспечение ZeroTier, изучив исходный код на официальной странице проекта на GitHub.

      Воспользуйтесь консолью SSH для подключения к недавно созданному серверу и запустите следующую команду с помощью обычного пользователя (объяснение команды приведено ниже). Убедитесь, что вы не используете его как пользователя с правами root, поскольку скрипт автоматически запрашивает пароль для повышения уровня привилегий, а также обязательно оставьте консоль ZeroTier открытой в браузере, чтобы вы могли взаимодействовать с ней при необходимости.

      • curl -s 'https://pgp.mit.edu/pks/lookup?op=get&search=0x1657198823E52A61' | gpg --import && if z=$(curl -s 'https://install.zerotier.com/' | gpg); then echo "$z" | sudo bash; fi

      После завершения работы скрипта вы увидите две строки вывода, аналогичные представленным ниже. Запишите адрес ZeroTier (без квадратных скобок) и имя системы, которая генерирует адрес, потому что эти данные потребуются вам позднее:

      Output

      *** Waiting for identity generation... *** Success! You are ZeroTier address [ 916af8664d ].

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

      Шаг 3 — Подключение к сети ZeroTier

      Теперь, когда на сервере и на клиенте установлено и запущено программное обеспечение ZeroTier, вы можете подключить их к сети, которую вы создали в веб-консоли ZeroTier.

      Используйте следующую команду, чтобы указать вашему клиенту запрашивать доступ к сети ZeroTier через его платформу. Первоначальный запрос клиента будет отклонен и оставлен в подвешенном состоянии, но мы сможем исправить это за секунду. Обязательно замените NetworkID на идентификатор сети, представленный в окне конфигурации сети, который вы записали ранее.

      • sudo zerotier-cli join NetworkID

      Output

      200 join OK

      Вы получите сообщение 200 join OK, подтверждающее, что служба ZeroTier на вашем сервере приняла команду. В ином случае еще раз проверьте идентификатор сети ZeroTier, который вы ввели.

      Поскольку вы создали не публичную сеть, к которой может подключиться любой пользователь в мире, вам нужно будет авторизовать клиентов. Перейдите в веб-консоль ZeroTier и прокрутите до самого конца до раздела Members (Участники). Вы должны найти две записи, помеченные Online (Онлайн), с теми же адресами, которые вы записали ранее.

      В первом столбце, помеченном *Auth? *(Авторизация?), поставьте галочки, чтобы разрешить им подключиться к сети. Контроллер ZeroTier будет выделять IP-адрес для сервера и клиента из адресного пространства, которое вы выбрали ранее. Этот адрес они будут использовать при следующем вызове SDN.

      Выделение IP-адресов может занять определенное время. Во время ожидания вы можете указать Short Name (Короткое имя) и Description (Описание) для ваших узлов в разделе Members (Участники).

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

      К настоящему моменту вы кратко познакомились с панелью управления ZeroTier, использовали интерфейс командной строки для загрузки и установки ZeroTier, а затем подключили сервер и клиент к этой сети. Далее вам необходимо проверить, что все было применено корректно, выполнив тест подключения.

      Шаг 4 — Проверка подключения

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

      Найти IP-адрес каждого хоста ZeroTier проще всего в разделе Members (Участники) в веб-консоли ZeroTier. Вам может потребоваться обновить его после авторизации сервера и клиента, прежде чем их IP-адреса появятся в данном разделе. Кроме того, вы можете воспользоваться командной строкой Linux для поиска этих адресов. Используйте следующую команду на обоих компьютерах — первый IP-адрес в списке будет адресом, который необходимо использовать. В представленном ниже примере это адрес 203.0.113.0.

      • ip addr sh zt0 | grep 'inet'

      Output

      inet 203.0.113.0/24 brd 203.0.255.255 scope global zt0 inet6 fc63:b4a9:3507:6649:9d52::1/40 scope global inet6 fe80::28e4:7eff:fe38:8318/64 scope link

      Чтобы протестировать подключение между хостами, запустите команду ping из одного хоста, добавив к ней IP-адрес другого хоста. Например, это может выглядеть так на компьютере-клиенте:

      И так на сервере:

      Если от противоположного хоста будет получен ответ (как показано в выводе ниже), можно считать, что оба узла успешно передают данные через SDN.

      Output

      PING 203.0.113.0 (203.0.113.0) 56(84) bytes of data. 64 bytes from 203.0.113.0: icmp_seq=1 ttl=64 time=0.054 ms 64 bytes from 203.0.113.0: icmp_seq=2 ttl=64 time=0.046 ms 64 bytes from 203.0.113.0: icmp_seq=3 ttl=64 time=0.043 ms

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

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

      Шаг 5 — Активация функции VPN в ZeroTier

      Как было отмечено во введении, вы можете использовать ZeroTier в качестве инструмента VPN. Если вы не планируете использовать ZeroTier в качестве решения для организации VPN, вы можете пропустить этот шаг и перейти сразу к шагу 6.

      Использование VPN скрывает источник вашей коммуникации с веб-сайтами в Интернете. Это позволяет вам обойти фильтры и ограничения, которые могут существовать в сети, которую вы используете. В отношении более широкого Интернета, вы сможете использовать публичный IP-адрес вашего сервера. Чтобы использовать ZeroTier в качестве инструмента VPN, вам придется внести ряд дополнительных изменений в конфигурацию вашего сервера и клиента.

      Активация преобразования сетевых адресов и IP-передачи

      Преобразование сетевых адресов, обычно именуемое NAT (Network Address Translation), — это метод, с помощью которого маршрутизатор принимает пакеты на одном интерфейсе с IP-адресом отправителя, а затем меняет этот адрес на адрес маршрутизатора. Запись этой замены сохраняется в памяти маршрутизатора, чтобы при возвращении трафика, идущего в противоположном направлении, маршрутизатор смог перевести IP-адрес обратно на первоначальный. NAT обычно используется, чтобы позволить нескольким компьютерам использовать один общедоступный IP-адрес, что очень удобно при использовании VPN. Примером использования NAT на практике является домашний роутер, который ваш интернет-провайдер предоставляет вам для подключения всех устройств в вашем доме к сети Интернет. Ваш ноутбук, телефон, планшет и любые другие устройства с поддержкой сети Интернет, скорее всего, используют один открытый IP-адрес в Интернете, поскольку ваш маршрутизатор использует NAT.

      Хотя NAT обычно выполняется маршрутизатором, сервер также может использовать эту технологию. На данном шаге вы сможете реализовать эту функцию на вашем сервере ZeroTier для активации VPN.

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

      С помощью активации передачи IP-адреса VPN трафик вашего клиента в сети ZeroTier будет направляться на интерфейс ZeroTier на сервере. Без этих изменений конфигурации ядро Linux будет (по умолчанию) удалять любые пакеты, которые не предназначены для интерфейса, на который они прибывают. Это нормальное поведение для ядра Linux, поскольку, как правило, любые пакеты, которые будут прибывать на интерфейс, имеющие в качестве адреса назначения адрес другой сети, могут быть вызваны некорректной конфигурацией в других местах сети.

      Полезно рассматривать передачу IP-адреса как информирование ядра Linux о том, что оно может пересылать пакеты между интерфейсами. Настройка по умолчанию 0, что является эквивалентом значения “Выкл”. Вы должны задать значение 1, что является эквивалентом значения “Вкл”.

      Для просмотра текущей конфигурации запустите следующую команду:

      • sudo sysctl net.ipv4.ip_forward

      Output

      net.ipv4.ip_forward = 0

      Чтобы активировать передачу IP-адреса, измените файл /etc/sysctl.conf на вашем сервере и добавьте необходимую строку. Этот файл конфигурации позволяет администратору переопределять параметры ядра по умолчанию и будет всегда применяться после перезагрузки, поэтому вам не придется беспокоиться о том, чтобы настраивать его снова. Используйте nano или свой любимый текстовый редактор, чтобы добавить следующую строку внизу файла.

      • sudo nano /etc/sysctl.conf

      /etc/sysctl.conf

      . . .
      net.ipv4.ip_forward = 1
      

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

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

      • sudo sysctl net.ipv4.ip_forward

      Output

      net.ipv4.ip_forward = 1

      Теперь, когда передача IP-адреса активирована, вы сможете ее использовать, задав несколько базовых правил маршрутизации для сервера. Поскольку в ядре Linux уже присутствует поддержка сетевой маршрутизации, вам нужно будет только добавить определенные правила, которые будут указывать встроенному брандмауэру и маршрутизатору, что новый трафик, который они будут видеть, можно принимать, а также сообщать, куда его нужно переслать.

      Чтобы добавить эти правила из командной строки, вам сначала нужно узнать имена, которые Ubuntu присвоила вашему интерфейсу ZeroTier и вашему интерфейсу локальной сети с выходом в Интернет. Как правило, это zt0 и eth0 соответственно, хотя это не всегда так.

      Чтобы найти имена этих интерфейсов, используйте команду ip link show​​​. Эта утилита командной строки является частью iproute2, набора утилит пользовательского пространства, которые будут устанавливаться в Ubuntu по умолчанию:

      В выводе этой команды имена интерфейсов находятся рядом с номерами, которые определяют уникальный интерфейс в списке. Эти имена интерфейсов выделены в следующем примере вывода. Если ваши имена отличаются от имен, представленных в данном примере, замените ваши имена на соответствующие для использования в данном руководстве.

      Output

      1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 72:2d:7e:6f:5e:08 brd ff:ff:ff:ff:ff:ff 3: zt0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2800 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000 link/ether be:82:8f:f3:b4:cd brd ff:ff:ff:ff:ff:ff

      Получив эту информацию, воспользуйтесь iptables, чтобы активировать преобразование сетевых адресов и IP-маскарадинг.

      • sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

      Разрешите перенаправление трафика и отслеживание активных соединений:

      • sudo iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

      Далее разрешите перенаправление трафика с zt0 на eth0. Обратное правило не требуется, поскольку в рамках данного руководства предполагается, что клиент всегда вызывается через сервер, а не наоборот:

      • sudo iptables -A FORWARD -i zt0 -o eth0 -j ACCEPT

      Важно помнить, что правила iptables, которые вы задали для сервера, не сохраняются автоматически между перезагрузками. Вам нужно будет отдельно сохранить эти правила, чтобы они продолжали действовать после перезагрузки сервера. Запустите перечисленные ниже команды на сервере, следуя кратким инструкциям на экране, чтобы сохранить текущие правила для IPv4, правила для IPv6 не требуются.

      • sudo apt-get install iptables-persistent
      • sudo netfilter-persistent save

      После запуска sudo netfilter-persistent save рекомендуется перезагрузить ваш сервер, чтобы подтвердить, что правила iptables были сохранены корректно. Самым удобным способом проверки является запуск команды sudo iptables-save, которая будет выводить текущую конфигурацию, загруженную в память, на терминал. Если вы увидите правила, аналогичные правилам ниже, действующие в отношении маскарадинга, перенаправления и интерфейса zt0, это значит, что они были сохранены корректно.

      Output

      # Generated by iptables-save v1.6.0 on Tue Apr 17 21:43:08 2018 . . . -A POSTROUTING -o eth0 -j MASQUERADE COMMIT . . . -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i zt0 -o eth0 -j ACCEPT COMMIT . . .

      Теперь, когда эти правила были применены на вашем сервере, вы можете перебрасывать трафик между сетью ZeroTier и общедоступной сетью Интернет. Однако VPN не будет работать, если сама сеть ZeroTier не будет знать о том, что сервер готов к использованию в качестве шлюза.

      Активация вашего сервера для управления глобальным маршрутом

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

      Перейдите в верхнюю часть страницы сети ZeroTier и добавьте новый маршрут со следующими параметрами. Вы можете найти IP-адрес вашего сервера в сети ZeroTier в разделе Members (Участники) на странице конфигурации сети ZeroTier. В поле network/bits (сеть/биты) введите значение 0.0.0.0/0, а в поле (LAN) (Локальная сеть) введите IP-адрес вашего сервера ZeroTier.

      Когда все данные будут сохранены, нажмите символ “+”, после чего вы увидите новое правило под существующим правилом. Правило будет иметь оранжевый глобус, который служит сигналом о том, что это глобальный маршрут:

      Правило глобального маршрута

      Теперь, когда ваша сеть ZeroTier готова к работе, осталось добавить только одну конфигурацию, чтобы VPN заработал. Это конфигурация клиентов.

      Настройка клиентов Linux

      Примечание: команды в данном разделе применяются только для клиентов Linux. Инструкции по настройке клиентов Windows или macOS содержатся в следующем разделе.

      Если ваш клиент работает в операционной системе Linux, вам нужно будет вручную внести изменения в файл /etc/sysctl.conf. Это изменение конфигурации необходимо, чтобы поменять представление ядра о приемлемом пути возвращения вашего клиентского трафика. Из-за того, как настроен VPN в ZeroTier, иногда может казаться, что трафик, который ваш сервер возвращает клиенту, имеет другой сетевой адрес, чем адрес, на который он был отправлен. По умолчанию ядро Linux рассматривает это как ошибку и отклоняет трафик, что делает необходимым переопределение такого поведения.

      Откройте /etc/sysctl.conf на клиентском компьютере:

      • sudo nano /etc/sysctl.conf

      А затем добавьте следующую строку:

      Output

      . . . net.ipv4.conf.all.rp_filter=2

      Сохраните и закройте файл, а затем запустите команду sudo sysctl -p, чтобы принять изменения.

      Далее укажите программному обеспечению клиента ZeroTier, что в вашей сети разрешен маршрут по умолчанию для трафика. Это изменяет маршрутизацию клиента и рассматривается как привилегированная функция, поэтому ее нужно активировать вручную. Команда будет выводить структуру конфигурации. Проверьте это, чтобы убедиться, что она отображает allowDefault=1 в верхней части:

      • sudo zerotier-cli set NetworkID allowDefault=1

      Если вы в какой-либо момент времени захотите прекратить использование ZeroTier в качестве VPN со всей вашей маршрутизацией трафика, задайте обратно значение 0 для allowDefault:

      • sudo zerotier-cli set NetworkID allowDefault=0

      При каждом перезапуске службы ZeroTier на клиентском компьютере значение allowDefault=1 будет сбрасываться до 0. Не забывайте повторно указать его, чтобы активировать функции VPN.

      По умолчанию для службы ZeroTier задается автоматический запуск при загрузке как для клиента Linux, так и для сервера. Если вы не хотите, чтобы служба запускалась автоматически, вы можете отключить стандартный процесс запуска с помощью следующей команды.

      • sudo systemctl disable zerotier-one

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

      Настройка работающих не под Linux клиентов

      Программное обеспечение ZeroTier доступно для многих систем, а не только для Linux. Поддерживаются даже смартфоны. Существуют клиенты для Windows, macOS, Android, iOS и даже таких специализированных операционных систем, как QNAP, Synology и WesternDigital NAS.

      Чтобы подключить к системе клиенты на базе macOS и Windows, запустите инструмент ZeroTier (который вы установили на шаге 1) и введите ваш сетевой идентификатор в доступное поле, а затем нажмите Join (Подключиться). Не забудьте зайти в консоль и поставить галочку Allow (Разрешить), чтобы авторизовать новый хост в вашей сети.

      Также необходимо обязательно проставить галочку в поле Route all traffic through ZeroTier (Направлять весь трафик через ZeroTier). Если вы не сделаете этого, ваш клиент будет подключен к вашей сети ZeroTier, но не будет пытаться пересылать свой интернет-трафик через эту сеть.

      Используйте инструмент для проверки IP, например, ICanHazIP, чтобы убедиться, что ваш трафик отправляется в сеть Интернет через IP-адрес вашего сервера. Чтобы проверить это, вставьте следующий URL-адрес в адресную строку браузера. Этот веб-сайт отображает IP-адрес, который его сервер (и остальной Интернет) видит, когда вы заходите на сайт:

      http://icanhazip.com
      

      После выполнения этих действий вы сможете начать использование VPN, когда захотите. Следующий дополнительный раздел описывает технологию, которая опирается на ZeroTier SDN и называется “правила потока”, но она не является необходимой для работы VPN.

      Шаг 6 — Управление потоками (дополнительно)

      Одним из преимуществ программно-конфигурируемой сети является централизованный контроллер. В ZeroTier централизованный контроллер — это пользовательский веб-интерфейс, который располагается поверх всей службы ZeroTier SDN. С помощью данного интерфейса вы можете задавать правила, известные как правила потока. Эти правила определяют, какой трафик допускается в сети, а какой нет. Например, вы можете задать полный запрет на использование определенных сетевых портов, передающих трафик по всей сети, ограничить, какие хосты могут общаться друг с другом, и даже перенаправлять трафик.

      Это очень мощный инструмент, который дает результат почти мгновенно, поскольку любые изменения в таблице потока передаются участникам сети и вступают в силу в считанные секунды. Чтобы изменить правила потока, вернитесь в пользовательский веб-интерфейс ZeroTier, нажмите вкладку Networking (Сеть) и прокрутите до поля Flow Rules (Правила потока) (оно может быть свернуто и вам потребуется развернуть его). В результате откроется текстовое поле, где вы можете ввести любые правила, какие захотите. Полное руководство доступно в консоли ZeroTier в поле, расположенном непосредственно под полем для ввода Flow Rules (Правила потока), которое называется Rules Engine Help (Справка для обработчика правил).

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

      Чтобы заблокировать любой трафик, идущий с DNS-сервера Google 8.8.8.8, добавьте следующее правило:

      drop
          ipdest 8.8.8.8/32
      ;
      

      Чтобы перенаправить любой трафик, идущий с открытого DNS-сервера Google, на один из узлов ZeroTier, добавьте следующее правило. Это отличный способ перехвата любых переопределенных DNS-поисков:

      redirect NetworkID
          ipdest 8.8.8.8/32
      ;
      

      Если у вашей сети есть особые требования безопасности, вы можете запретить любую активность через FTP-порты, Telnet и незашифрованный HTTP-протокол, добавив следующее правило:

      drop
          dport 80,23,21,20
      ;
      

      Когда вы закончите добавлять правила потока, нажмите кнопку Save Changes (Сохранить изменения), после чего ZeroTier запишет изменения.

      Заключение

      С помощью данного руководства вы сделали свои первые шаги в мире программно-конфигурируемых сетей, а работа с ZeroTier предоставила вам некоторую информацию о преимуществах этой технологии. Если вы выполняли указания в примере, посвященном VPN, хотя первоначальная настройка может отличаться от других инструментов, которые вы использовали в прошлом, то простота добавления дополнительных клиентов может стать убедительной причиной использования этой технологии в других местах.

      В качестве вывода необходимо отметить, что вы узнали, как использовать ZeroTier в качестве поставщика SDN, а также настраивать узлы и добавлять узлы в сеть. Посвященный VPN раздел даст вам более полное представление о том, как работает маршрутизация в такой сети, а дополнительная часть данного руководства поможет вам использовать мощную технологию правил потока.

      Теперь, когда существует сеть с двухточечным соединением, вы можете объединить ее с другим функционалом, например совместным доступом к файлам. Если у вас есть NAS или файловый сервер, вы можете подключить его к ZeroTier и получать к нему доступ без каких-либо проблем и сложностей. Если вы захотите поделиться им с друзьями, вам нужно будет только показать им, как подключиться к сети ZeroTier. Сотрудники, работающие в самых разных физических точках, могут даже подключаться к одному центральному хранилищу. Для начала создания общего файлового ресурса для любого из этих примеров ознакомьтесь с руководством Настройка файлообменника Samba для небольшой организации на Ubuntu 16.04.



      Source link

      Как создать кластер Kubernetes с помощью Kubeadm в Ubuntu 16.04


      Автор выбрал фонд Free and Open Source Fund для получения пожертвования в рамках программы Write for DOnations.

      Введение

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

      Примечание. В этом обучающем руководстве используется версия Kubernetes 1.14, последняя официальная поддерживаемая версия на момент публикации данной статьи. Актуальную информацию о последней версии можно найти в текущих примечаниях к выпуску в официальной документации Kubernetes.

      Kubeadm автоматизирует установку и настройку компонентов Kubernetes, в том числе сервера API, Controller Manager и Kube DNS. Однако данное средство не создает пользователей и не выполняет установку зависимостей уровня операционной системы и их конфигурации. Для предварительных задач существует возможность использования инструментов управления конфигурацией, таких как Ansible и SaltStack. Использование этих инструментов упрощает создание дополнительных кластеров или воссоздание существующих кластеров, а также снижает вероятность ошибок.

      В этом обучающем модуле вы научитесь создавать кластер Kubernetes с помощью Ansible и Kubeadm, а затем развертывать в нем приложение Nginx в контейнерах.

      Цели

      Ваш кластер будет включать следующие физические ресурсы:

      • Один главный узел

      Главный узел (под узлом в Kubernetes подразумевается сервер), отвечающий за управление состоянием кластера. На нем работает система Etcd, которая хранит данные кластера среди компонентов, распределяющих рабочие задачи по рабочим узлам.

      • Два рабочих узла

      Рабочие узлы — это серверы, где выполняются рабочие нагрузки (т. е. приложения и службы в контейнерах). Рабочий узел продолжает выполнять назначенную нагрузку, даже если главный узел отключается после распределения задач. Добавление рабочих узлов позволяет увеличить объем кластера.

      После прохождения данного обучающего модуля вы получите кластер, готовый к запуску приложений в контейнерах, при условии, что серверы кластера имеют достаточные ресурсы процессорной мощности и оперативной памяти для выполнения этих приложений. Практически любые традиционные приложения Unix, в том числе веб-приложения, базы данных, демоны и инструменты командной строки, можно поместить в контейнеры и запускать в кластере. Сам кластер потребляет примерно 300-500 МБ оперативной памяти и 10% ресурсов процессора на каждом узле.

      После настройки кластера вы развернете веб-сервер Nginx для проверки правильного выполнения рабочей нагрузки.

      Предварительные требования

      Шаг 1 — Настройка директории рабочего пространства и файла инвентаризации Ansible

      В этом разделе вы создадите на локальном компьютере директорию, которая будет выступать в качестве рабочего пространства. Также вы выполните локальную настройку Ansible, чтобы обеспечить возможность связи с вашими удаленными серверами и выполнения команд на этих серверах. Для этого вы создадите файл hosts с данными инвентаризации, в том числе с IP-адресами ваших серверов и данными групп, к которым принадлежит каждый сервер.

      Из трех ваших серверов один сервер будет главным сервером, и его IP-адрес будет отображаться как master_ip. Другие два сервера будут рабочими узлами и будут иметь IP-адреса worker_1_ip и worker_2_ip.

      Создайте директорию ~/kube-cluster в домашней директории локального компьютера и перейдите в нее с помощью команды cd:

      • mkdir ~/kube-cluster
      • cd ~/kube-cluster

      В рамках этого обучающего руководства данная директория будет выступать в качестве рабочего пространства, и в ней будут храниться все ваши плейбуки Ansible. Также в этой директории вы будете запускать все локальные команды.

      Создайте файл с именем ~/kube-cluster/hosts с помощью nano или своего любимого текстового редактора:

      • nano ~/kube-cluster/hosts

      Добавьте в файл следующий текст с информацией о логической структуре вашего кластера:

      ~/kube-cluster/hosts

      [masters]
      master ansible_host=master_ip ansible_user=root
      
      [workers]
      worker1 ansible_host=worker_1_ip ansible_user=root
      worker2 ansible_host=worker_2_ip ansible_user=root
      
      [all:vars]
      ansible_python_interpreter=/usr/bin/python3
      

      Возможно, вы помните, что файлы инвентаризации в Ansible используются для указания данных серверов, в том числе IP-адресов, удаленных пользователей и группировок серверов как единый объем для целей выполнения команд. Файл ~/kube-cluster/hosts будет вашим файлом инвентаризации, и вы добавили в него две группы Ansible (masters и workers) для определения логической структуры вашего кластера.

      В группе masters имеется запись сервера master, в которой указан IP-адрес главного узла (master_ip) и указывается, что система Ansible должна запускать удаленные команды от имени пользователя root.

      В группе workers также есть две записи для серверов рабочих узлов (worker_1_ip и worker_2_ip), где пользователь ansible_user также задается как пользователь root.

      В последней строке файла Ansible предписывается использовать для операций управления интерпретаторы Python 3 удаленных серверов.

      Сохраните и закройте файл после добавления текста.

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

      Шаг 2 — Создание пользователя без привилегий root на всех удаленных серверах

      В этом разделе вы создадите пользователя без привилегий root с привилегиями sudo на всех серверах, чтобы вы могли вручную подключаться к ним через SSH как пользователь без привилегий. Это полезно на случай, если вы захотите посмотреть информацию о системе с помощью таких команд, как top/htop, просмотреть список работающих контейнеров или изменить файлы конфигурации, принадлежащие пользователю root. Данные операции обычно выполняются во время технического обслуживания кластера, и использование пользователя без привилегий root для выполнения таких задач минимизирует риск изменения или удаления важных файлов или случайного выполнения других опасных операций.

      Создайте в рабочем пространстве файл с именем ~/kube-cluster/initial.yml:

      • nano ~/kube-cluster/initial.yml

      Добавьте в файл следующую строку сценария play для создания пользователя без привилегий root с привилегиями sudo на всех серверах. Сценарий в Ansible — это набор выполняемых шагов, нацеленных на определенные серверы и группы. Следующий сценарий создаст пользователя без привилегий root с привилегиями sudo:

      ~/kube-cluster/initial.yml

      - hosts: all
        become: yes
        tasks:
          - name: create the 'ubuntu' user
            user: name=ubuntu append=yes state=present createhome=yes shell=/bin/bash
      
          - name: allow 'ubuntu' to have passwordless sudo
            lineinfile:
              dest: /etc/sudoers
              line: 'ubuntu ALL=(ALL) NOPASSWD: ALL'
              validate: 'visudo -cf %s'
      
          - name: set up authorized keys for the ubuntu user
            authorized_key: user=ubuntu key="{{item}}"
            with_file:
              - ~/.ssh/id_rsa.pub
      

      Далее приведено детальное описание операций, выполняемых этим плейбуком:

      • Создает пользователя без привилегий root с именем ubuntu.

      • Настраивает файл sudoers, чтобы пользователь ubuntu мог запускать команды sudo без ввода пароля.

      • Добавляет на локальный компьютер открытый ключ (обычно ~/.ssh/id_rsa.pub) в список авторизованных ключей удаленного пользователя ubuntu. Это позволит вам подключаться к каждому серверу через SSH под именем пользователя ubuntu.

      Сохраните и закройте файл после добавления текста.

      Затем запустите плейбук на локальном компьютере:

      • ansible-playbook -i hosts ~/kube-cluster/initial.yml

      Выполнение команды займет от двух до пяти минут. После завершения вы увидите примерно следующий результат:

      Output

      PLAY [all] **** TASK [Gathering Facts] **** ok: [master] ok: [worker1] ok: [worker2] TASK [create the 'ubuntu' user] **** changed: [master] changed: [worker1] changed: [worker2] TASK [allow 'ubuntu' user to have passwordless sudo] **** changed: [master] changed: [worker1] changed: [worker2] TASK [set up authorized keys for the ubuntu user] **** changed: [worker1] => (item=ssh-rsa AAAAB3... changed: [worker2] => (item=ssh-rsa AAAAB3... changed: [master] => (item=ssh-rsa AAAAB3... PLAY RECAP **** master : ok=5 changed=4 unreachable=0 failed=0 worker1 : ok=5 changed=4 unreachable=0 failed=0 worker2 : ok=5 changed=4 unreachable=0 failed=0

      Теперь предварительная настройка завершена, и вы можете перейти к установке зависимостей Kubernetes.

      Шаг 3 — Установка зависимостей Kubernetes

      В этом разделе вы научитесь устанавливать требующиеся Kubernetes пакеты уровня операционной системы с помощью диспетчера пакетов Ubuntu. Вот эти пакеты:

      • Docker — среда исполнения контейнеров. Это компонент, который запускает ваши контейнеры. В настоящее время для Kubernetes активно разрабатывается поддержка других сред исполнения, в том числе rkt.

      • kubeadm — инструмент командной строки, который устанавливает и настраивает различные компоненты кластера стандартным образом.

      • kubelet — системная служба/программа, которая работает на всех узлах и обрабатывает операции на уровне узлов.

      • kubectl — инструмент командной строки, используемый для отправки команд на кластер через сервер API.

      Создайте в рабочем пространстве файл с именем ~/kube-cluster/kube-dependencies.yml:

      • nano ~/kube-cluster/kube-dependencies.yml

      Добавьте в файл следующие сценарии, чтобы установить данные пакеты на ваши серверы:

      ~/kube-cluster/kube-dependencies.yml

      - hosts: all
        become: yes
        tasks:
         - name: install Docker
           apt:
             name: docker.io
             state: present
             update_cache: true
      
         - name: install APT Transport HTTPS
           apt:
             name: apt-transport-https
             state: present
      
         - name: add Kubernetes apt-key
           apt_key:
             url: https://packages.cloud.google.com/apt/doc/apt-key.gpg
             state: present
      
         - name: add Kubernetes' APT repository
           apt_repository:
            repo: deb http://apt.kubernetes.io/ kubernetes-xenial main
            state: present
            filename: 'kubernetes'
      
         - name: install kubelet
           apt:
             name: kubelet=1.14.0-00
             state: present
             update_cache: true
      
         - name: install kubeadm
           apt:
             name: kubeadm=1.14.0-00
             state: present
      
      - hosts: master
        become: yes
        tasks:
         - name: install kubectl
           apt:
             name: kubectl=1.14.0-00
             state: present
             force: yes
      

      Первый сценарий в плейбуке выполняет следующие операции:

      • Устанавливает среду исполнения контейнеров Docker.

      • Устанавливает apt-transport-https, позволяя добавлять внешние источники HTTPS в список источников APT.

      • Добавляет ключ apt-key репозитория Kubernetes APT для проверки ключей.

      • Добавляет репозиторий Kubernetes APT в список источников APT ваших удаленных серверов.

      • Устанавливает kubelet и kubeadm.

      Второй сценарий состоит из одной задачи, которая устанавливает kubectl на главном узле.

      Примечание. Хотя в документации Kubernetes рекомендуется использовать для вашей среды последнюю стабильную версию Kubernetes, в данном обучающем руководстве используется конкретная версия. Это обеспечит успешное следование процедуре, поскольку Kubernetes быстро изменяется и последняя версия может не соответствовать этому обучающему руководству.

      Сохраните файл и закройте его после завершения.

      Затем запустите плейбук на локальном компьютере:

      • ansible-playbook -i hosts ~/kube-cluster/kube-dependencies.yml

      После завершения вы увидите примерно следующий результат:

      Output

      PLAY [all] **** TASK [Gathering Facts] **** ok: [worker1] ok: [worker2] ok: [master] TASK [install Docker] **** changed: [master] changed: [worker1] changed: [worker2] TASK [install APT Transport HTTPS] ***** ok: [master] ok: [worker1] changed: [worker2] TASK [add Kubernetes apt-key] ***** changed: [master] changed: [worker1] changed: [worker2] TASK [add Kubernetes' APT repository] ***** changed: [master] changed: [worker1] changed: [worker2] TASK [install kubelet] ***** changed: [master] changed: [worker1] changed: [worker2] TASK [install kubeadm] ***** changed: [master] changed: [worker1] changed: [worker2] PLAY [master] ***** TASK [Gathering Facts] ***** ok: [master] TASK [install kubectl] ****** ok: [master] PLAY RECAP **** master : ok=9 changed=5 unreachable=0 failed=0 worker1 : ok=7 changed=5 unreachable=0 failed=0 worker2 : ok=7 changed=5 unreachable=0 failed=0

      После выполнения на всех удаленных серверах будут установлены Docker, kubeadm и kubelet. kubectl не является обязательным компонентом и требуется только для выполнения команд кластера. В этом контексте имеет смысл производить установку только на главный узел, поскольку вы будете запускать команды kubectl только на главном узле. Однако следует отметить, что команды kubectl можно запускать с любых рабочих узлов и на любом компьютере, где их можно установить и настроить для указания на кластер.

      Теперь все системные зависимости установлены. Далее мы настроим главный узел и проведем инициализацию кластера.

      Шаг 4 — Настройка главного узла

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

      Под — это атомарная единица, запускающая один или несколько контейнеров. Эти контейнеры используют общие ресурсы, такие как файловые тома и сетевые интерфейсы. Под — это базовая единица планирования в Kubernetes: все контейнеры в поде гарантированно запускаются на том же узле, который назначен для этого пода.

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

      Эту функцию обеспечивают плагины сети подов. Для этого кластера мы используем стабильный и производительный плагин Flannel.

      Создайте на локальном компьютере плейбук Ansible с именем master.yml:

      • nano ~/kube-cluster/master.yml

      Добавьте в файл следующий сценарий для инициализации кластера и установки Flannel:

      ~/kube-cluster/master.yml

      - hosts: master
        become: yes
        tasks:
          - name: initialize the cluster
            shell: kubeadm init --pod-network-cidr=10.244.0.0/16 >> cluster_initialized.txt
            args:
              chdir: $HOME
              creates: cluster_initialized.txt
      
          - name: create .kube directory
            become: yes
            become_user: ubuntu
            file:
              path: $HOME/.kube
              state: directory
              mode: 0755
      
          - name: copy admin.conf to user's kube config
            copy:
              src: /etc/kubernetes/admin.conf
              dest: /home/ubuntu/.kube/config
              remote_src: yes
              owner: ubuntu
      
          - name: install Pod network
            become: yes
            become_user: ubuntu
            shell: kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/a70459be0084506e4ec919aa1c114638878db11b/Documentation/kube-flannel.yml >> pod_network_setup.txt
            args:
              chdir: $HOME
              creates: pod_network_setup.txt
      

      Далее приведена детализация этого сценария:

      • Первая задача инициализирует кластер посредством запуска kubeadm init. При передаче аргумента --pod-network-cidr=10.244.0.0/16 задается частная подсеть, из которой назначаются IP-адреса подов. Flannel использует вышеуказанную подсеть по умолчанию, и мы предпишем kubeadm использовать ту же подсеть.

      • Вторая задача создает директорию .kube по адресу /home/ubuntu. В этом каталоге будут храниться данные конфигурации, в том числе файлы ключа администратора, необходимые для подключения к кластеру, и адрес API кластера.

      • Третья задача копирует файл /etc/kubernetes/admin.conf, сгенерированный kubeadm init в домашней директории пользователя без привилегий root. Это позволит вам использовать kubectl для доступа к новому кластеру.

      • Последняя задача запускает kubectl apply для установки Flannel. Синтаксис kubectl apply -f descriptor.[yml|json] предписывает kubectl создать объекты, описанные в файле descriptor.[yml|json]. Файл kube-flannel.yml содержит описания объектов, требуемых для настроки Flannel в кластере.

      Сохраните файл и закройте его после завершения.

      Запустите плейбук на локальной системе с помощью команды:

      • ansible-playbook -i hosts ~/kube-cluster/master.yml

      После завершения вы увидите примерно следующий результат:

      Output

      PLAY [master] **** TASK [Gathering Facts] **** ok: [master] TASK [initialize the cluster] **** changed: [master] TASK [create .kube directory] **** changed: [master] TASK [copy admin.conf to user's kube config] ***** changed: [master] TASK [install Pod network] ***** changed: [master] PLAY RECAP **** master : ok=5 changed=4 unreachable=0 failed=0

      Чтобы проверить статус главного узла, подключитесь к нему через SSH с помощью следующей команды:

      Запустите на главном узле следующую команду:

      Результат будет выглядеть следующим образом:

      Output

      NAME STATUS ROLES AGE VERSION master Ready master 1d v1.14.0

      В результатах показано, что главный узел master завершил выполнение всех задач инициализации и находится в состоянии готовности Ready, из которого он может принимать подключения от рабочих узлов и выполнять задачи, отправленные на сервер API. Теперь вы можете добавить рабочие узлы с локального компьютера.

      Шаг 5 — Настройка рабочих узлов

      Для добавления рабочих узлов в кластер нужно запустить на каждом из них отдельную команду. Эта команда предоставляет всю необходимую информацию о кластере, включая IP-адрес, порт сервера API главного узла и защищенный токен. К кластеру могут подключаться только те узлы, которые проходят проверку с защищенным токеном.

      Вернитесь в рабочее пространство и создайте плейбук с именем workers.yml:

      • nano ~/kube-cluster/workers.yml

      Добавьте в файл следующий текст для добавления рабочих узлов в кластер:

      ~/kube-cluster/workers.yml

      - hosts: master
        become: yes
        gather_facts: false
        tasks:
          - name: get join command
            shell: kubeadm token create --print-join-command
            register: join_command_raw
      
          - name: set join command
            set_fact:
              join_command: "{{ join_command_raw.stdout_lines[0] }}"
      
      
      - hosts: workers
        become: yes
        tasks:
          - name: join cluster
            shell: "{{ hostvars['master'].join_command }} >> node_joined.txt"
            args:
              chdir: $HOME
              creates: node_joined.txt
      

      Вот что делает этот плейбук:

      • Первый сценарий получает команду join, которую нужно запустить на рабочих узлах. Эта команда имеет следующий формат: kubeadm join --token <token> <master-ip>:<master-port> --discovery-token-ca-cert-hash sha256:<hash>. После получения фактической команды с правильными значениями token и hash задача задает их как фактические, чтобы следующий сценарий имел доступ к этой информации.

      • Второй сценарий содержит одну задачу, которая запускает команду join на всех рабочих узлах. После завершения этой задачи два рабочих узла становятся частью кластера.

      Сохраните файл и закройте его после завершения.

      Запустите плейбук на локальном компьютере:

      • ansible-playbook -i hosts ~/kube-cluster/workers.yml

      После завершения вы увидите примерно следующий результат:

      Output

      PLAY [master] **** TASK [get join command] **** changed: [master] TASK [set join command] ***** ok: [master] PLAY [workers] ***** TASK [Gathering Facts] ***** ok: [worker1] ok: [worker2] TASK [join cluster] ***** changed: [worker1] changed: [worker2] PLAY RECAP ***** master : ok=2 changed=1 unreachable=0 failed=0 worker1 : ok=2 changed=1 unreachable=0 failed=0 worker2 : ok=2 changed=1 unreachable=0 failed=0

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

      Шаг 6 — Проверка кластера

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

      Вам нужно будет проверить текущее состояние кластера с главного узла, чтобы убедиться в готовности всех узлов. Если вы отключились от главного узла, вы можете снова подключиться к нему через SSH с помощью следующей команды:

      Затем выполните следующую команду, чтобы получить данные о статусе кластера:

      Вы увидите примерно следующий результат:

      Output

      NAME STATUS ROLES AGE VERSION master Ready master 1d v1.14.0 worker1 Ready <none> 1d v1.14.0 worker2 Ready <none> 1d v1.14.0

      Если на всех ваших узлах отображается значение Ready для параметра STATUS, это означает, что они являются частью кластера и готовы к выполнению рабочих нагрузок.

      Если же на некоторых узлах отображается значение NotReady для параметра STATUS, это может означать, что настройка рабочих узлов еще не завершена. Подождите от пяти до десяти минут, а затем снова запустите команду kubectl get node и проверьте полученные результаты. Если для некоторых узлов по-прежнему отображается статус NotReady, вам нужно проверить и заново запустить команды, которые выполнялись на предыдущих шагах.

      Теперь кластер успешно проверен, и мы запланируем запуск на кластере образца приложения Nginx.

      Шаг 7 — Запуск приложения на кластере

      Теперь вы можете развернуть на кластере любое приложение в контейнере. Для удобства мы развернем Nginx с помощью Deployments (развертывания) и Services (службы) и посмотрим, как можно развернуть это приложение на кластере. Вы можете использовать приведенные ниже команды для других приложений в контейнерах, если вы измените имя образа Docker и дополнительные параметры (такие как ports и volumes).

      Запустите на главном узле следующую команду для создания развертывания с именем nginx:

      • kubectl create deployment nginx --image=nginx

      Развертывание — это тип объекта Kubernetes, обеспечивающий постоянную работу определенного количества подов на основе заданного шаблона даже в случае неисправности пода в течение срока службы кластера. Вышеуказанное развертывание создаст под с одним контейнером из образа Nginx Docker в реестре Docker.

      Запустите следующую команду, чтобы создать службу nginx, которая сделает приложение общедоступным. Для этого используется схема NodePort, которая делает под доступным на произвольном порту, который открывается на каждом узле кластера:

      • kubectl expose deploy nginx --port 80 --target-port 80 --type NodePort

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

      Запустите следующую команду:

      Будет выведен текст следующего вида:

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 1d nginx NodePort 10.109.228.209 <none> 80:nginx_port/TCP 40m

      В третьей сроке результатов указан номер порта, на котором запущен Nginx. Kubernetes автоматически назначает случайный порт с номером выше 30000 и при этом проверяет, не занят ли этот порт другой службой.

      Чтобы убедиться в работе всех элементов, откройте адрес http://worker_1_ip:nginx_port или http://worker_2_ip:nginx_port в браузере на локальном компьютере. Вы увидите знакомую начальную страницу Nginx.

      Если вы захотите удалить приложение Nginx, предварительно удалите службу nginx с главного узла:

      • kubectl delete service nginx

      Запустите следующую команду, чтобы проверить удаление службы:

      Результат будет выглядеть следующим образом:

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 1d

      Затем удалите развертывание:

      • kubectl delete deployment nginx

      Запустите следующую команду для проверки успешности выполнения:

      Output

      No resources found.

      Заключение

      В этом обучающем модуле вы научились успешно настраивать кластер Kubernetes в Ubuntu 16.04, используя для автоматизации Kubeadm и Ansible.

      Если вы не знаете, что дальше делать с настроенным кластером, попробуйте развернуть на нем собственные приложения и службы. Далее приведен список ссылок с дополнительной информацией, которая будет вам полезна:

      • Докеризация приложений — детальные примеры контейнеризации приложений с помощью Docker.

      • Обзор подов — детальное описание принципов работы подов и их отношений с другими объектами Kubernetes. Поды используются в Kubernetes повсеместно, так что понимание этой концепции упростит вашу работу.

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

      • Обзор служб — рассказывает о службах, еще одном часто используемом объекте кластеров Kubernetes. Понимание типов служб и доступных для них опций важно для использования приложений с сохранением состояния и без сохранения состояния.

      Другие важные концепции, полезные при развертывании рабочих приложений: тома, входы и секреты.

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



      Source link