Описание
Продолжение проекта, описанного в посте AWS: билд Java + Maven + Docker + Packer + Terraform — будем разворачивать нечто аналогичное в Китае.
Хотя у Китая есть «свой AWS» — Aliyun.com, принадлежащий Alibaba Group, тем не менее — мы будем пользоваться именно Amazon Web Services.
В этом посте не будет HowTo do something — больше просто описание опыта работы с Китаем.
Пара полезных ссылок:
- — оф. описание от Amazon
- AWS China(Beijing) Region Tips — про особенности работы с AWS China
Сервисы
Первое, что бросается в глаза — это количество сервисов — тут их намного меньше.
Например, консоль в Европе выглядит так:
А в Китае — так:
Список всех сервисов и их наличие по регионам можно посмотреть .
Скорость
Вторая проблема — скорость.
Например, открыть страницу китайского AWS, даже просто curl-ом, из Киева:
Тест скорости с iperf из датацентра «Воля» в Киеве:
59.1 Kbits/sec? Где-то такое уже видели, только 56к:
На самом деле скорость варьируется — иногда всё работает более-менее живо, иногда — отмирает напрочь.
ICP license
Ещё один немаловажный (критический, я бы сказал момент) — это .
Вопросами лицензии занимались менеджеры, потому деталей не знаю, но хороший обзор на эту тему есть .
Кратко говоря — вы не можете запустить вебсайт (вообще любой сервис, который работает по портам 80, 443, пока не знаю по поводу 8080 и использует доменное имя), не получив разрешения от властей Китая, а именно — от Ministry of Industry and Information Technology. Не в курсе — как на счёт других сервисов (почта, базы и т.д.), но что касается веб — без лицензии не обойтись.
Пример лицензии можно увидеть тут — , слева внизу:
Или даже на странице самого китайского :
Процесс получения лицезии выглядит примерно так:
Начало работы
Начнём работу с настройки профиля:
Образы Ubuntu, как обычно — можно найти на .
И первый «упс» — в Китае нет t2.nano:
Docker test
Запускаем интанс:
Первое, что требуется проверить — скорость загрузки образов с серверов JFrog Artifactory, которые расположены в Европе.
Планируется использование уже имеющегося Jenkins в Европе, который будет собирать образы и пушить их в Artifactory, после чего скрипт на китайских инстансах будет делать docker pull и переключать Blue и Green окружения.
Устанавливаем Docker:
Скорость… При apt-get update, даже несмотря на то, что большая часть данных тянется из китайского репозитория Ubuntu () — update выполнялся минут 10, а весь процесс установки Docker из этого скрипта — минут 30.
Ждём, несколько раз отлавливая ошибки вида:
…
E: Failed to fetch https://apt.dockerproject.org/repo/pool/main/d/docker-engine/docker-engine_17.04.0~ce-0~ubuntu-xenial_amd64.deb Operation too slow. Less than 10 bytes/sec transferred the last 120 seconds
…
Собственно — попытка pull:
Почти 8 минут для образа в 237 мб — для нас приемлемо, тем более последующие загрузки будут быстрее.
Terraform
Для создания окружений (и для деплоя, но не в этом случае) — у нас имеются шаблоны Terrafrom:
А для быстрого запуска — я когда-то писал bash-скрипт:
#!/usr/bin/env bash
# Do NOT use thi script ever!
# For testing environmtnt only
AWS_ACCESS_KEY_ID="AKI***L5A"
AWS_SECRET_ACCESS_KEY="OtN***7Cb"
AWS_REGION="cn-north-1"
USERNAME="docker"
PASSWORD="M8f***XSC"
DOCKER_TAG=$1
[[ -z $DOCKER_TAG ]] && { echo "Specify Docker tag as first argument."; exit 1; }
TF_BACK_PATH="dev-cn"
EC2KEY="tag-cn"
VPC_CIDR="10.0.0.0/16"
SPRING_PROFILE=dev-cn
terraform get
terraform_config () {
terraform remote config \
-backend=artifactory \
-backend-config="username=${USERNAME}" \
-backend-config="password=${PASSWORD}" \
-backend-config="url=https://engineering.artifactoryonline.com/engineering/tag-terraform/" \
-backend-config="repo=api" \
-backend-config="subpath=${TF_BACK_PATH}"
}
terraform_plan () {
terraform plan \
-var region=${AWS_REGION} \
-var aws_access_key=${AWS_ACCESS_KEY_ID} \
-var aws_secret_key=${AWS_SECRET_ACCESS_KEY} \
-var ssh_key_name=${EC2KEY} \
-var vpc_cidr_block=${VPC_CIDR} \
-var 'public_subnet_cidr_blocks={ "0" = "10.0.0.0/24", "1" = "10.0.1.0/24" }' \
-var 'private_subnet_cidr_blocks={ "0" = "10.0.2.0/24", "1" = "10.0.3.0/24" }' \
-var spring_profile=${SPRING_PROFILE} \
-var docker_image_tag=${DOCKER_TAG} \
-var min_size_green=1 \
-var min_size_blue=0 \
-var max_size=8
}
terraform_apply () {
terraform apply \
-var region=${AWS_REGION} \
-var aws_access_key=${AWS_ACCESS_KEY_ID} \
-var aws_secret_key=${AWS_SECRET_ACCESS_KEY} \
-var ssh_key_name=${EC2KEY} \
-var vpc_cidr_block=${VPC_CIDR} \
-var 'public_subnet_cidr_blocks={ "0" = "10.0.0.0/24", "1" = "10.0.1.0/24" }' \
-var 'private_subnet_cidr_blocks={ "0" = "10.0.2.0/24", "1" = "10.0.3.0/24" }' \
-var spring_profile=${SPRING_PROFILE} \
-var docker_image_tag=${DOCKER_TAG}
}
terraform_plan_destroy () {
terraform plan -destroy \
-var region=${AWS_REGION} \
-var aws_access_key=${AWS_ACCESS_KEY_ID} \
-var aws_secret_key=${AWS_SECRET_ACCESS_KEY} \
-var ssh_key_name=${EC2KEY} \
-var vpc_cidr_block=${VPC_CIDR} \
-var 'public_subnet_cidr_blocks={ "0" = "10.0.0.0/24", "1" = "10.0.1.0/24" }' \
-var 'private_subnet_cidr_blocks={ "0" = "10.0.2.0/24", "1" = "10.0.3.0/24" }' \
-var spring_profile=${SPRING_PROFILE}
}
terraform_destroy () {
terraform destroy \
-var region=${AWS_REGION} \
-var aws_access_key=${AWS_ACCESS_KEY_ID} \
-var aws_secret_key=${AWS_SECRET_ACCESS_KEY} \
-var ssh_key_name=${EC2KEY} \
-var vpc_cidr_block=${VPC_CIDR} \
-var 'public_subnet_cidr_blocks={ "0" = "10.0.0.0/24", "1" = "10.0.1.0/24" }' \
-var 'private_subnet_cidr_blocks={ "0" = "10.0.2.0/24", "1" = "10.0.3.0/24" }' \
-var spring_profile=${SPRING_PROFILE}
}
#terraform_config || exit 1
#terraform_plan || exit 1
terraform_apply || exit 1
#terraform_plan_destroy || exit 1
#terraform_destroy || exit 1
Запускаем, пробуем:
Странно, но ок — добавляем AIM роль AdministratorAccess, пробуем снова (прим. — роль администратора не помогла, см. ниже).
Вторая ошибка — из-за соединения. Работа из Киева в Китай будет аукаться ещё много раз:
…
* aws_security_group.http_out: Error waiting for Security Group (sg-e7fa5f83) to become available: timeout while waiting for state to become ‘exists’ (timeout: 1m0s)
…
Перезапускаем.
Проблемы
Ещё одна ошибка:
Просто консоль не сумела подгрузить данные. Ну, ок…
Вот ещё — Connection reset:
Ещё ошибка:
А ещё можем так:
Так мы и закончили первый день… 🙂
Ещё несколько раз выскакивала ошибка вида:
…
* data.aws_ami.eureka_green: data.aws_ami.eureka_green: AuthFailure: AWS was not able to validate the provided access credentials
status code: 401, request id: c534dca9-d35f-408c-a310-86bf1bfc53dc
…
Но перезапуск помогал. Причём появляется она рандомно, независимо от типа ресурса — иногда при создании VPC, иногда — EC2 интанса.
Продолжение тут>>>.
