Как док-машина может создать экземпляр EC2 в частной подсети?

Question

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

export server_name=tomcat-5 

docker-machine create \ 
    --driver amazonec2 \ 
    --amazonec2-region us-west-2 \ 
    --amazonec2-vpc-id vpc-8e5488ea \ 
    --amazonec2-ami ami-6f69a25f \ 
    --amazonec2-instance-type m3.medium \ 
    --amazonec2-zone b \ 
    --amazonec2-subnet-id subnet-52f5dd54 \ 
    --amazonec2-security-group tomcat-sg-SecurityGroup-JHHNDKKL4LO1 \ 
    --amazonec2-tags Name,${server_name} \ 
    --amazonec2-root-size 10 \ 
    --amazonec2-ssh-user ec2-user \ 
    --amazonec2-ssh-keypath ~/.ssh/id_rsa \ 
    --amazonec2-private-address-only \ 
    ${server_name} 

Это говорит

Running pre-create checks... 
Creating machine... 
(tomcat-5) Launching instance... 
Waiting for machine to be running, this may take a few minutes... 
Detecting operating system of created instance... 
Waiting for SSH to be available... 

и после того, что он просто висит навсегда. Очевидно, он не знает, как добраться до сервера через бастион. И я не могу назвать сервер, чтобы докер мог использовать .ssh/config (если он это сделает).

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

Что мне не хватает?

Answer 1

Я смог получить дополнительную информацию о проблеме, включив отладку. По существу

docker-machine --debug.... 

Это позволило мне увидеть, что Докер-машина пытается SSH в IP с ec2-user@10.x.y.z с этими параметрами

{[-F /dev/null -o PasswordAuthentication=no -o StrictHostKeyChecking=no 
-o UserKnownHostsFile=/dev/null -o LogLevel=quiet -o ConnectionAttempts=3 
-o ConnectTimeout=10 -o ControlMaster=no -o ControlPath=none ec2-user@10.x.y.z 
-o IdentitiesOnly=yes -i /Users/jvarg/.docker/machine/machines/tomcat-2/id_rsa 
-p 22] /usr/bin/ssh <nil>} 

ближе. Я смог напрямую загрузить ssh в машину, обновив файл ~/.ssh/config, создав прокси для моей подсети. Но докер-машина не использует этот файл конфигурации. Как вы можете видеть, он использует/dev/null. "-F/dev/null".

Я смотрел в коде машины докера, и это кажется жестким. https://github.com/docker/machine/blob/df2d3811ca8bc9ddf6896b4a4154b9277826b441/libmachine/ssh/client.go#L69

Я создал проблему на github для отслеживания. https://github.com/docker/machine/issues/3794

Обновление: Пока мы ожидаем, что этот PR, который будет принят (теперь застрял с конфликтами слияния), является обходным решением. Войдите в бастион и используйте его в качестве оркестра вместо своего ноутбука. На бастионе установите докер и докер-машину. Также убедитесь, что вы создаете новую пару ключей, чтобы не нарушать свою собственную. Я не установил агент ssh. Поэтому, если вы идете одинаково, убедитесь, что пара ключей не имеет пропущенной фразы. Вы сможете, наконец, войти в него. Но это будет потом не с

notifying bugsnag: [Error creating machine: Error running provisioning: exit status 1] 

Хотя это не очевидно из этой ошибки, подробный анализ результатов отладки показал, что он терпел неудачу, потому что новая машина не смогла выйти в Интернет. Обычно это не проблема для большинства из вас. В моем случае мы используем http_proxy. Но я решил это, установив шлюз NAT.

Следующая ошибка состояла в том, что бастион не мог связаться с портом 2376 с новой машиной. Обычно докер-машина создает группу безопасности с открытым доступом к миру 2376. Моя компания недовольна открытыми портами. Поэтому я обновил свой SG, чтобы разрешить доступ с бастиона. Но я думаю, мне нужно настроить его.