Как автоматически перезапускать плейбук?

#bash #ansible #devops

                    
Конфигурация проходит через VPN и возникают периодические отваливания в соединении,
что приводит к остановке плейбука для данного хоста.

Если в самом Ansible инструмент, перезапускающий плейбук до тех пор, пока .retry
не останется пустым?

Пока вижу выход в небольшом баш скрипте с whle true циклом.
    

Ответы

Ответ 1

Подобных средств на уровне плейбука не знаю, а бесконечный while это откровенный
костыль. 

Вам могут помочь следующие вещи:


включите pipelining в скриптах ansible чтобы увеличить скорость выполнения скрипта
увеличьте таймаут ssh на своём сервере
включите в конфиге retries
если вышеперечисленное не помогло, то подумайте о режиме ansible-pull (выполнять
скрипты локально на самом сервере)


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

---
- hosts: all
  connection: local
  tasks:
      - shell: exit 1
        register: task_result
        until: task_result.rc == 0
        retries: 10
        delay: 1
        ignore_errors: yes

Построение эффективной CI/CD инфраструктуры с нуля начинающему devops инженеру

#c_sharp #angular2 #docker #непрерывная_интеграция #devops

Предыстория.

На работе встала задача, наше новое приложение, разработанное на asp.net core и Angular
по серьёзному развернуть на серверах компании. Инженеров devops нет и не предвидится,
поэтому мне как старшему разработчику придётся осваивать и это направление т.к. команда
и так не большая - всего 4 человека. В общем, проблема возникла на стадии планирования. 

Сейчас в компании используются две независимые гальванически не связанные сети для
интернета и для внутренней подсети. Вся инфраструктура (1с и прочее) находятся именно
в локальной сети без доступа из вне. Разработчики напротив сидят именно в интернетовском
сегменте. 

Обдумывая инфраструктуру серверов для публикации и тестирования проекта я обдумывал
использовать Docker.(Само приложение будет использовать linux в качестве серверной
платформы(nginx для angular, postgresql - db, api на .net core). 

Небольшая выжимка информации.


Windows; Visual studio 2017 для разработки API; Visual studio code для Angular; GitLab
на внутренем интернет сервере;
API написано с использованием ASP.NET Core 2; Клиент на Angular 4; DB - postgresql;
Разработчики находятся в отдельной сети от места развертывания приложения;
Сервера с приложением будут в локальной сети без доступа к интернету;
В качестве базовой платформы будет использоваться ProxMox в локальной сети;


Структура получившаяся на мой взгляд.



Вот только есть несколько проблем (собственно вопросов):


Обновление пакетов NPM(в качестве пакетного менеджера используется Yarn) и NuGet.
Добавление новых пакетов.  Вроде, как и для nuget и для Yarn можно делать offline зеркала,
но как поддерживать в них актуальность? И есть ли возможность обновлять/добавлять пакеты
используя Git? м.б. кто-то сталкивался с этим?
Есть ли вообще смысл от Гипервизора и виртуальных машин? Или в данной ситуации лучше
на одной физической машине развернуть всё? Есть ли плюс поддержки виртуальных машин
(в будущем планировалось объединить несколько серверов в кластер и добавить репликацию
с резервированием)?
Возможно ли что я иду в неправильном направлении и все мои идеи и мысли в корне не
верны? Будет ли мне потом мучительно больно при работе со всем этим? :)
Где вообще можно почитать об организации такой структуры с нуля?  


Возможно кто-то подскажет как лучше организовать весь этот процесс CI/CD. Для меня
это первый опыт в этом направлении и всё хочется сделать правильно (на сколько это
возможно)) ведь мне самому придётся работать со всей этой структурой и как разработчику
и как devops.
    

Ответы

Ответ 1

Обновление пакетов NPM(в качестве пакетного менеджера используется
  Yarn) и NuGet. Добавление новых пакетов. Вроде, как и для nuget и для
  Yarn можно делать offline зеркала, но как поддерживать в них
  актуальность? И есть ли возможность обновлять/добавлять пакеты
  используя Git? м.б. кто-то сталкивался с этим?


Большинство пакетных менеджеров могу скачивать репозитории по ssh / git. 
yarn install git+ssh://git@github.com//.git. С nuget видимо только
репозитории. Пока это не проблема, а будущая возможная оптимизация, по уменьшению трафика
и увеличению скорости билдов. Спокойно игнорируем на этом этапе.


  Есть ли вообще смысл от Гипервизора и виртуальных машин? Или в данной
  ситуации лучше на одной физической машине развернуть всё? Есть ли плюс
  поддержки виртуальных машин (в будущем планировалось объединить
  несколько серверов в кластер и добавить репликацию с резервированием)?


Смысл есть - изоляция, но и overhead. Как плюс gold image, в котором уже все готово,
нужно только залить весь стек (docker stack deploy).
Вполне можно ужиться и на одном, более рисковый путь.
Для кластера - docker-swarm + glusterfs / edge fs / etc (для overlay volumes).


  Возможно ли что я иду в неправильном направлении и все мои идеи и
  мысли в корне не верны? Будет ли мне потом мучительно больно при
  работе со всем этим? :)


Направление верное. Мучительно ли? - Да, как и всё новое.
Мой пример - docker-swarm около месяца (две из них auto letsencrypt + nginx).
Просто потому что выбрал инструмент, который знал. После на Traefik сделал за два дня. 

Автоматизировать, нужно постепенно. Сделать CI. Deploy ручной, но c одной командой.
По началу даже так ускорится процесс (Fail Fast). 

Ни слова не упомянули о конфигурационной менеджменте. Тут Ansible в помощь. По ссылке
мой опыт автоматизации деплоя на swarm cluster, а так же структура, которая позволит
быстро добавить новые сервисы и задеплоить. 

Конечно есть нюансы, типа нельзя воспользоваться deploy script, пока нету registry.
Или workflow c множеством docker-compose.*.yml файлов. Плюс полная докеризация (как
пример) или DevSecOps.


  Где вообще можно почитать об организации такой структуры с нуля?


Подписаться на DevOps рассылки, настроить google alerts по темам (docker, container,
etc). Повышать кругозор. Накладывать свои знания на свою реальность. И много экспериментировать.

Настройка CI/CD для публикации приложения в Azure

#visual_studio #aspnet #azure #непрерывная_интеграция #devops

Хочу использовать Visual Studio Team Services для сборки и публикации своего ASP.NET
приложения в Azure Web Application. Раньше публиковал с помощью Web Deploy в Visual
Studio, и там мой профиль публикации содержал следующие данные:


Строка подключение к базе SQL Azure
Параметры для включения аутентификации в Azure AD


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

Вопрос: есть ли способ внести в Build Definition эти настройки? Импортировать профиль
публикации при развертывании или еще какие-либо способы корректно развернуть приложение
в облаке?
    

Ответы

Ответ 1

Если вы публикуете приложение именно как  Azure Web Application, то вам не нужно
править конфиги на стадии билда. 


Вынесите настройки в web.config, в стандартные секции ConnectionStrings и AppSettings.
Они должны быть там по умолчанию, но вдруг вы храните из где-то в другом месте.
В портале Azure, в секции Application settings для своего приложения - задайте реальные
значения для своего приложения.




Значения из Application settings применяются поверх того, что вписано в web.config,
так что вам вообще ничего не придется заменять в процессе сборки и публикации релиза.

Официальная документация по настройкам: Configure web apps in Azure App Service.

App settings:


  For .NET apps, these settings are injected into your .NET configuration AppSettings
at runtime, overriding existing settings.


Connection strings:


  For .NET apps, these connection strings are injected into your .NET configuration
connectionStrings settings at runtime, overriding existing entries where the key equals
the linked database name.




Кстати, Azure Web Sites умеют автопубликацию из GIT / VSTS, со встроенной поддержкой
основных типов студийных проектов, так что может быть вам вообще не нужны билды в VSTS :)

Добавление нового репозитория в ansible скрипте

Мне надо выполнить следующий набор команд с помощью ansible
apt-get update && apt-get install -y apt-transport-https curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - cat </etc/apt/sources.list.d/kubernetes.list deb http://apt.kubernetes.io/ kubernetes-xenial main EOF apt-get update apt-get install -y kubelet kubeadm kubectl
Проблемы начинаются со второй строчки. Через ansible делаю так:
- name: curl curl command: sudo curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
В ответ получаю ошибку:
[WARNING]: Consider using 'become', 'become_method', and 'become_user' rather than running sudo
fatal: [default]: FAILED! => {"changed": true, "cmd": ["sudo", "curl", "-s", "https://packages.cloud.google.com/apt/doc/apt-key.gpg", "|", "sudo", "apt-key", "add", "-"], "delta": "0:00:00.037295", "end": "2018-02-14 07:25:50.272885", "failed": true, "msg": "non-zero return code", "rc": 2, "start": "2018-02-14 07:25:50.235590", "stderr": "curl: option -: is unknown
curl: try 'curl --help' or 'curl --manual' for more information", "stderr_lines": ["curl: option -: is unknown", "curl: try 'curl --help' or 'curl --manual' for more information"], "stdout": "", "stdout_lines": []}
Как выполнить такую команду правильно? Пробовал добавить строку sudo: true и убрать sudo в команде. Ошибка не пропадает.

Ответ

Ну вот как-то так наверное:
- name: Install Kubernetes 4 Ubuntu when: ansible_distribution == 'Ubuntu' become: yes block: - apt: name: apt-transport-https state: latest - apt_repository: repo: deb http://apt.kubernetes.io/ kubernetes-{{ ansible_distribution_release }} main state: present filename: kubernetes - apt_key: url: https://packages.cloud.google.com/apt/doc/apt-key.gpg state: present - apt: update_cache: yes force: yes - apt: name: "{{ item }}" state: present install_recommends: yes with_items: - kubelet - kubeadm - kubectl

Настройка CI/CD для публикации приложения в Azure

Хочу использовать Visual Studio Team Services для сборки и публикации своего ASP.NET приложения в Azure Web Application. Раньше публиковал с помощью Web Deploy в Visual Studio, и там мой профиль публикации содержал следующие данные:
Строка подключение к базе SQL Azure Параметры для включения аутентификации в Azure AD
Теперь же, когда публикация происходит с помощью CI/CD конвейера, эти параметры не подставляются и приложение публикуется в облако со строкой подключения и параметрами, которые были на локальной машине.
Вопрос: есть ли способ внести в Build Definition эти настройки? Импортировать профиль публикации при развертывании или еще какие-либо способы корректно развернуть приложение в облаке?

Ответ

Если вы публикуете приложение именно как Azure Web Application, то вам не нужно править конфиги на стадии билда.
Вынесите настройки в web.config, в стандартные секции ConnectionStrings и AppSettings. Они должны быть там по умолчанию, но вдруг вы храните из где-то в другом месте. В портале Azure, в секции Application settings для своего приложения - задайте реальные значения для своего приложения.

Значения из Application settings применяются поверх того, что вписано в web.config, так что вам вообще ничего не придется заменять в процессе сборки и публикации релиза.
Официальная документация по настройкам: Configure web apps in Azure App Service
App settings:
For .NET apps, these settings are injected into your .NET configuration AppSettings at runtime, overriding existing settings.
Connection strings:
For .NET apps, these connection strings are injected into your .NET configuration connectionStrings settings at runtime, overriding existing entries where the key equals the linked database name.

Кстати, Azure Web Sites умеют автопубликацию из GIT / VSTS, со встроенной поддержкой основных типов студийных проектов, так что может быть вам вообще не нужны билды в VSTS :)