/Task 1
../Asgoret
../../Solution.md

Хотим предоставить Вам тестовое задание, чтобы Вы могли понять с чем Вам придется работать, а мы могли оценить Ваш потенциал.
Тестовое задание выполняется на 2х отдельных тестовых площадках (в нашем случае 2 виртуальных машинах).
Предоставьте Ваш публичный ключ SSH, чтоб мы могли дать доступ к площадкам.

Site C: SSH lab@vm-1:9023
Internal network 172.31.234.80/28 (addresses 172.31.234.83-172.31.234.94 can be used)
Private network 192.168.2.0/24

Site A SSH lab@vm-2:9023
Internal network 172.31.228.144/28 (addresses 172.31.228.147-172.31.228.158 can be used)
Private network 192.168.3.0/24

Задание
1) Создать на каждой из площадок:
1.1) контейнер с web-сервером (достаточно странички Hello World, с выводом текущего времени сервера и его имени хоста), использовать адрес из соответствующего Internal network
1.2) контейнер с базой данных и авторитативным NS-сервером для зоны devops.task.com, зону брать из Б/Д, использовать адрес из соответствующего Private network, добавить произвольные записи (например,www.devops.task.com) для web-серверов
1.3) зафорвардить запросы dns, приходящие на каждую из нод, в её контейнер p.1.2
2) Поднять IPsec между площадками и обеспечить маршрутизацию через него Private-подсетей 192.168.2.0/24 и 192.168.3.0/24
3) Настроить репликацию баз данных с п.1.2 с одной из площадок на другую либо обеспечить их взаимную репликацию
4) Организовать синхронизацию контента web-серверов p.1.1 с какого-либо общего репозитария или с одного из их инстансов
5) Заскриптовать клонирование (опционально - удаление ранее созданного клона) контейнера p.1.1 и обновление Б/Д NS п. 1.2 для включения его в зону devops.task.com


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

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

Как я говорила, у нас в компании предусматривается выполнение тестового задания кандидатами, которые нас заинтересовали, поэтому высылаю его Вам.

Условие:
Для любой Unix-like системы необходимо написать скрипт(ы) для установки/удаления/обновления заведомо неизвестных нам пакетов из файлов (.rpm или .deb или любых других на Ваше усмотрение). После установки пакетов, необходимо перезапускать сервис, имя которого передается как параметр. Проверить, что пакеты установлены, а сервис запущен. Предусмотреть в скрипте исключительные ситуации, например, пакет(ы) уже установлен(ы). Скрипт должен логировать свои действия и иметь help. Также на Ваше усмотрение реализуйте в скрипте любую интересную функцию. Например, создание бэкапов или «пасхалку». Дистрибутив, пакетный менеджер, сервис остаются на Ваше усмотрение. Нет строгих ограничений по реализации скрипта.



Возник вопрос по поводу задания: "заведомо неизвестных нам пакетов из файлов" - что у меня есть на входе? папка с пакетами? названия пакетов?


Любые файлы на Ваше усмотрение.

Задание:
1) Зарегистрироваться в Amazon
2) Создать свой VPC, публичный subnet
3) Создать ASG минимального размера, произвольной линухи на вкус
4) Создать AWS ALB, связать c новоиспеченным ASG
5) Завести внутренню зону *my-nginx.interna* l через Route53
6) на ASG тачке(ах) должен происходить следующий бутстрап:
        - Устанавливаться Docker Engine
        - С ремоутного репозитория качаться "docker-compose" файл, где будет собираться/ранаться следующее:
              стандартный nginx, который выводит текст "Hello, i am Nginx on instance: ${instance_id}"

Дополнение на *:
7*) Создать AWS ECR, загрузить образ nginx туда и уже оттуда забирать стандартный образ вместо публичной репы
8*) *my-nginx.internal* должен быть доступен по https, добавить самоподписанный SSL сертификат

Ограничения:
    -    Тулы\Cloud, которым нужно научиться\проверить знания: git, terraform, ansible, aws
    -    Мелкие баш-скрипты разрешены
        -       Можно использовать другие тулы, но с крепким обоснованием почему тулы выше не подходят
    -    Код должен храниться в публичном доступе, например, на гитхабе
    -    Обязательное README.md, чтобы не гадать о последовательности  подготовительных действий

Ожидаемые действия:
1. Чтение README.md, пред-подготовка
2. Запуск terraform
3. Смотреть в браузер как отрабатывает ALB, получая сообщеньку от nginx(ов) по адресу my-nginx.internal

Dockerize Hadoop Cluster (from Linux Exam), in two dockers - namenode and worker.
 Create a public repo on DockerHub (any name, up to you)
 Create 2 Dockerfiles for namenode and worker repsectively
 Create images and push them into this repo
 provide me a links to your repos and names of images. Also provide source Dockerfiles
I should be able to start 2 containers from these  images and get working Hadoop cluster. Imagine that I have no idea of what to run and which ports to forward - make everything self-exlanatory.
 additional task: create docker-compose.yml to start the whole Hadoop cluster through one compose file.

Жизнь нашей компании проходит в достаточно обширном мире web-технологий. В процессе работы нам приходится постоянно сталкиваться с различными решениями и ПО. Одним из самых распространённых способов взаимодействия с web-сервисами является API, поэтому нашим сотрудникам необходимо не только владеть теоретическими знаниями об этом способе, как он принципиально устроен, уметь правильно понимать и обрабатывать ответы от сервера и коды ошибок, но и быстро знакомиться с новыми программными интерфейсами, предоставляемыми тем или иным прикладным ПО.

В нашей компании тоже есть ряд как внутренних, так и внешних сервисов со своим API, который используется и нами самими, и нашими клиентами. Одним из таких сервисов является Nixys Employee, предназначенный для взаимодействия с соискателями на должность Linux-администратора в нашу компанию. Таким образом, кандидату необходимо сначала получить текст тестового задания, сформировав и отправив на сервер правильный запрос. А уже после этого непосредственно переходить к решению полученного задания.

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

Ниже приводится документация по работе с API Nixys Employee.

---

Base URL: https://employee.nixys.ru/api/v1

API call description: get the pilot task.
Query type: GET
Query format: /task/{level}
Parameters:
    level: pilot task level. Available values: `low` or `high`
Response content type: application/json
Response structure:
    status:
        Type: text
        Description: field contains operation processing status. Can take values either `ok` or `error`.
    text:
        Type: text
        Description: field contains either pilot task text or error text.
Response codes:
    HTTP/200: Ok
    HTTP/400: wrong value for parameter {level}.

 Оно аналогично первому, только тебе требуется поднять не один сервер, а 3 одинаковых таких. И взамен обычного MySQL использовать MySQL Percona XtraDB Cluster (синхронную репликацию). Площадки будут ходить локально на каждом сервере по адресу localhost:3307 (тут будет слушать HAProxy), за который будет с health check стоять MySQL Percona XtraDB Cluster. 

Для синхронной репликации файлов требуется использовать Ceph или GlusterFS в реплике 3. 

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

Какую архитектуру web-приложения (например, система продаж) выбрать?
Microservices или well-architectured monolith?
Как попадают в production приложения в Вашем CI/CD pipeline? Деплоить ли с
помощью Ansible, Terraform? Или может быть мы уже готовы к Spinnaker(у)?
Нужен ли нам оркестратор? Зачем и какой именно выбрать? (Kubernetes, Docker
swarm, Mesos, Hashicorp Nomad, AWS ECS)
Выкатили новую версию и обнаружили опечатку на главной странице. Сколько
времени нужно, чтобы задеплоить в production в Вашем текущем CI/CD pipeline?
CI/CD для приложений организовали, а как бесперебойно и безопасно доставлять
изменения для инфраструктуры?
Нужен ли нам multicloud (AWS + Google Cloud + Azure + DigitalOcean)?
Как раздавать пользователям со всего мира дистрибутивы Intellij IDEA (~500 Мб) (и
прочих десктопных продуктов JetBrains) и чтобы support не засыпали жалобами на
низкую скорость или недоступность файлов для скачивания в Китае.
Как построить хорошую систему отправки email-сообщений из приложений?
Для чего нам в проекте может быть полезным serverless?
Autoscaling приложений: на основе чего его построить и проблемы скалирования
вверх-вниз?
Подход “Immutable/Disposable infrastructure”: чем он удобен, зачем нужен, какими
средствами(утилитами) будем реализовывать?
Кто деплоит в production (devops, админ, разработчик, QA-инженер или может быть
bash script или AWS Lambda function)? Насколько просто/сложно задеплоить
приложение в production?
Разработчик сломал/повредил базу на staging-стеке в ходе своих экспериментов и
просит “перезалить с production(a)”. Ваши действия?
Для чего может быть нужен ssh доступ к production-машинами и как его выдать?
Как секреты (пароли, ключи итд) попадают в приложение? Где секреты лучше
хранить? Как обеспечить на staging-стеках одни секреты, а на production - другие.
Что нужно учесть при настройке SSL termination (например, на nginx) в 2018 году?
Ваш опыт с WAF (web application firewall)?
Пришло сообщение от системы мониторинга одного из серверов production
backend(a) “No space left on device”. Что делать? (“df -klh” не показывает ни одного
полностью занятого диска..)
У Вас есть план по disaster recovery Вашего production-стека? Что в нем описано?
Давно Вы его проверяли (в тестовых целях)?
Service discovery и service mesh. Что это? Зачем нужно? Ваш опыт?
Расскажите о методах восстановления базы AWS RDS (MySQL 5.6) (какие методы
доступны, как их выполнить итд)
Защита от DDOS. Какие методы применяли? Был ли реальный опыт?
Практические советы по построению хороших docker images
Схемы деплоймента: их преимущества и недостатки. Какую схем[у|ы] используете
Вы и почему?
Внедряли ли вы систему distributed tracing для приложений? Насколько успешно?
Каковы Ваши выводы?
IP адрес, на котором работает Ваш сервис на AWS попал под блокировку РКН. Что
будете делать?
Расскажите как работает внедренный Вами конвейер сборки docker images?
Ваш опыт по мониторингу Java приложения в production(e). На что (на какие
метрики) стоит первым делом настроить алерты? Ваши действия, если после
очередного деплоя распределенного приложения появилась утечка памяти
(memory leak)?

Есть 3 репо с app -
apps самые что ни на есть простые вроде dev/ops. Единственное условие - apps
используют файлик .env для общения с БД и каждый работает на произвольном порте
(выбор порта на усмотрение, где номер порта > 1024);
Предусловие:
На terraform описать создание vpc, subnets, security groups
- Задача А:
Реализовать пайплайн, который автоматически при коммите в любую ветку
любого из 3-ёх репо будет по триггеру пуллить код из этой ветки и запускать сборку
артефакта - докер образ - и класть его в соответствующий ECR (например:
000000.dev.ops.ИМЯ_РЕГИОНА.amazonaws.com/ИМЯ ПРИЛОЖЕНИЯ/) и тегировать
именем ветки из которой был собран этот образ; если артефакт прилетел из мастера, то
тегируем его как latest;
Условия: для создания образа не использовать мастер ноду дженкинса, а
создавать сборочную ноду (через плагин Amazon EC2 Fleet Plugin или подобный,
например) у которой idle TTL ~ 300 sec
- Задача Б:
Реализовать пайплайн в дженкинсе, который будет собирать наши apps (из
задачи A) воедино и деплоить их как стек, используя docker swarm.
Условия:
Как и в задаче А сборку проводить на сборочной ноде (не мастере)
Вручную задавать имя стека;

Реализовать возможность ручками выбрать образ из ECR для каждого из app

С помощью пайплайна поднять инстанс на который задеплоится стек - для
поднятия инстанса использовать terraform файл;

Инстанс должен тегироваться тегами вида “имя репозитория": "имя ветки”, а
также тегом Owner со значением юзера, который запустил сборку билда -
используйте всё тот же terraform файл;

Создать базу данных с именем стека и таблицами для каждого app (таблицы
обозвать именами app соответственно);

Каждый из app должен быть доступен internal DNS имени (типа
dev.ops.tasks) - записи должны создаваться во время поднятия инсанса, с
помощью всё того же terraform

Для обработки запросов к apps использовать прокси (на ваш выбор: haproxy, caddy, nginx,
traefik, envoy). Прокси должен уметь обрабатывать запросы к отдельным app.
Также должен быть доступен условный main.ops.tasks (простой index,
который даст доступ сразу ко всем 3 apps)

Задача В:

Написать пайплайны (по одному на действия из списка ниже), которые будут
давать возможность вручную:
-
выбирать из списка запущенных инстансов и останавливать
выбранный инстанс, на котором запущен стек;
- выбирать из списка остановленных инстансов и запускать выбранный
инстанс;
- выбирать из списка всех имеющихся стеков и терминейтить
выбранный стек вместе с БД

Case
1
We use AWS for hosting our solution
2
For operating our infrastructure we need a HA Consul cluster distributed over at least 3
availability zones
3
The setup and maintenance should be fully automated
4
Consul instances should discover themselves using DNS
Task
Automate the deployment and management of a Consul cluster
-
Choose a concept/tool to automate the deployment and provisioning of the needed
AWS resources and servers
-
Implement and test your solution
-
Provide us with a git repository showing not only the result, but also the way you’ve
taken to implement your solution

На https://github.com надо создать репозиторий, где положить описание для создания Docker контейнера в котором надо сделать установку с нуля Redmine http://www.redmine.org, потом можно усложнить и разбить установку на три контейнера - БД, сервер приложений (Redmine+puma), фронтенд (nginx) и запускать это все при помощи docker-compose, все результаты работы также положить на гитхаб, Напиши, как закончишь, наши инженеры посмотрят. Также, вместо редмайна можно взять любое веб-приложение или написать свое, тут есть простор для творчества.
Необязательное задание со звездочкой: подключить Travis CI для сборки docker образа Redmine, его тестирования и публикации на docker hub.

Необходимо выстроить и описать процесс CI/CD для web-проекта, работа которого организована в docker-контейнерах. Входные данные:
* Язык программирования: PHP 7.3
* Стек технологий, задействованых в работе проекта: PHP-FPM, MySQL
* Система управления репозиториями: Gitlab
* Система CI/CD: Gitlab CI
* Менеджер репозиториев Docker: Goharbor
* Система оркестрации Docker: Docker-compose / k8s
* Система хранения секретов: Gitlab env/Vault
* Имется 3 сервера для размещения приложения, по одному на каждую среду окружения - dev, stage, prod
* Имеется 1 tools-сервер, на котором располагается Gitlab, 2 контейнера с Gitlab-runner (один под dev/stage окружения и еще один - для prod), Goharbor
* Для процессов CI в dev/stage и prod средах должны использоваться разные runner
* Обновление кода в dev,stage средах должно происходить по push в соответствующую ветку, в prod - при выставлении тэга
* Необходимо предусмотреть возможность отката на предыдушую версию кода

В качестве результата работы необходимо предоставить:
* доступы к репозиторию Gitlab
* все docker-compose файлы/манифесты Kubernetes - для самого приложения на PHP, Gitlab, Gitlab-runner, Goharbor и Vault (если будет задействован)
* текстовый документ с подробным описанием реализованной схемы и пояснениями ключевых моментов