AWS [China]: начало

Описание

Продолжение проекта, описанного в посте AWS: билд Java + Maven + Docker + Packer + Terraform – будем разворачивать нечто аналогичное в Китае.

Хотя у Китая есть “свой AWS” – Aliyun.com, принадлежащий Alibaba Group, тем не менее – мы будем пользоваться именно Amazon Web Services.

В этом посте не будет HowTo do something – больше просто описание опыта работы с Китаем.

Пара полезных ссылок:

• Introducing AWS in China – оф. описание от Amazon
• AWS China(Beijing) Region Tips – про особенности работы с AWS China

• Сервисы
• Скорость
• ICP license
• Начало работы
• Docker test
• Terraform
• Проблемы

Сервисы

Первое, что бросается в глаза – это количество сервисов – тут их намного меньше.

Например, консоль в Европе выглядит так:

А в Китае – так:

Список всех сервисов и их наличие по регионам можно посмотреть тут>>>.

Скорость

Вторая проблема – скорость.

Например, открыть страницу китайского AWS, даже просто curl-ом, из Киева:

Тест скорости с iperf из датацентра “Воля” в Киеве:

59.1 Kbits/sec? Где-то такое уже видели, только 56к:

На самом деле скорость варьируется – иногда всё работает более-менее живо, иногда – отмирает напрочь.

ICP license

Ещё один немаловажный (критический, я бы сказал момент) – это ICP license.

Вопросами лицензии занимались менеджеры, потому деталей не знаю, но хороший обзор на эту тему есть тут>>>.

Кратко говоря – вы не можете запустить вебсайт (вообще любой сервис, который работает по портам 80, 443, пока не знаю по поводу 8080 и использует доменное имя), не получив разрешения от властей Китая, а именно – от Ministry of Industry and Information Technology. Не в курсе – как на счёт других сервисов (почта, базы и т.д.), но что касается веб – без лицензии не обойтись.

Пример лицензии можно увидеть тут – http://bj.58.com, слева внизу:

Или даже на странице самого китайского AWS Console:

Процесс получения лицезии выглядит примерно так:

Начало работы

Начнём работу с настройки профиля:

Образы Ubuntu, как обычно – можно найти на Ubuntu Amazon EC2 AMI Finder.

И первый “упс” – в Китае нет t2.nano:

Docker test

Запускаем интанс:

Первое, что требуется проверить – скорость загрузки образов с серверов JFrog Artifactory, которые расположены в Европе.

Планируется использование уже имеющегося Jenkins в Европе, который будет собирать образы и пушить их в Artifactory, после чего скрипт на китайских инстансах будет делать docker pull и переключать Blue и Green окружения.

Устанавливаем Docker:

Скорость… При apt-get update, даже несмотря на то, что большая часть данных тянется из китайского репозитория Ubuntu (http://cn-north-1b.clouds.archive.ubuntu.com/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 интанса.

Продолжение тут>>>.