private hosted instance with non-interactive shell

[Jesse Yates]

Hi,

I'm trying to get the dockerized version of Cloudbreak deployed (ala cloudbreak-deployer v1.0.3) and am spinning it up, for the moment, in a Vagrant container. After working through the issues of CentOS + Docker, I came to realize that I cannot run the docker instances with a non-interactive shell, ie the vagrant provisioning process. The error it gives me is:

==> cloudbreak: * Dependency required, installing sed latest ...
==> cloudbreak: * Dependency required, installing jq latest ...
==> cloudbreak: * Dependency required, installing docker-compose latest ...
==> cloudbreak: * Dependency required, installing aws latest ...
==> cloudbreak: Unable to find image 'alpine:latest' locally
==> cloudbreak: latest: Pulling from library/alpine
==> cloudbreak: 8a648f689ddb: Pulling fs layer
==> cloudbreak: 8a648f689ddb: Verifying Checksum
==> cloudbreak: 8a648f689ddb: Download complete
==> cloudbreak: 8a648f689ddb: Pull complete
==> cloudbreak: Digest: sha256:fb9f16730ac6316afa4d97caa5130219927bfcecf0b0ce35c01dcb612f449739
==> cloudbreak: Status: Downloaded newer image for alpine:latest
==> cloudbreak: cannot enable tty mode on non tty input
==> cloudbreak: Generating Cloudbreak client certificate and private key in /vagrant/cloudbreak-deployment/certs.
==> cloudbreak: generating docker-compose.yml
==> cloudbreak: generating uaa.yml
==> cloudbreak: cannot enable tty mode on non tty input

...

==> cloudbreak: Status: Downloaded newer image for gliderlabs/registrator:v5
==> cloudbreak: docker.io/gliderlabs/registrator: this image was pulled from a legacy registry.  Important: This registry version will not be supported in future versions of docker.
==> cloudbreak: Cannot start container fbb77c39d0b0c9e0f5a58def58a28f92b8adaa6abf364228597aabd7c610a640: Cannot link to a non running container: /cbreak_consul_1 AS /cbreak_registrator_1/cbreak_consul_1
==> cloudbreak: cannot enable tty mode on non tty input

It still brings up the containers, but won't bring up the UI (http://10.200.0.3:3000) with a redirect to what seems to be an auth error.

I think its due to https://github.com/docker/docker/issues/8755, but my docker-fu is weak. I can run the same startup process after logging in and all the containers come up fine.  Here's a link to the vagrant file I'm using.

When you go into the logs from the vagrant provisioner-based start, you see:

cbd logs uluwatu

...

uluwatu_1 | App listening on port 3000
uluwatu_1 | No session found, websocket notifications won't work [socket ID: bEkeYNBG_PDFukp7AAAA] Error: could not look up session by key: connect.sid
uluwatu_1 | Subscribing client to Cloudbreak notifications
uluwatu_1 | GET / 302 12.314 ms - 686
uluwatu_1 | Exception error occurred: ECONNREFUSED when try to connect: backend:8089/oauth/token

 cbd logs cloudbreak
...
cloudbreak_1 | 2015-10-13 16:53:45,576 [localhost-startStop-1] validate:151 ERROR o.h.t.h.SchemaValidator - [owner:spring] [type:springLog] [id:] [name:] HHH000319: Could not get database metadata
cloudbreak_1 | org.postgresql.util.PSQLException: Connection refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections.
cloudbreak_1 |     at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:207) ~[postgresql-9.3-1101-jdbc41.jar!/:na]
cloudbreak_1 |     at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:64) ~[postgresql-9.3-1101-jdbc41.jar!/:na]

Has anyone else seen something like this? Should I even by trying to get this spun up to support a production deployment? I'm looking to eventually deploying custom apps alongside a subset of a standard HDP and need some auditing, so I think I will need to have my own instance.

Versions:
Vagrant 1.7.4
Docker 1.8.3
 - API 1.20
 - Go go1.4.2
Cloudbreak Deployer 1.0.3
Guest OS: 7.1.1503-x86_64

Thanks,
Jesse Yates

[Jesse Yates]

Slight update in running instructions:
 - to run the install, from the directory where the vagrant file is stored/run, you also need a vagrant/ directory and the version of cloudbreak-deployer (saves some download on multiple attempts)
Otherwise, should run as expected.

Note on running: `cbd generate` apparently also kicks off a VM, which leads to the same kind of tty error as above, generating incorrect configs. You would need to run generate from an interactive shell (or store the configs in vagrant/cloudbreak-deployment). Updating the vagrant file accordingly.

Still no solution though.

[gipsz...@gmail.com]

Hi Jesse,

Unfortunately we do not support Vagrant. We recommend that you deploy cloudbreak into the same cloud provider, where you want to provision the Hadoop cluster itself.

For example on AWS we provide az automatically built (by packer)  image which has the latest version of docker, and latest version of cbd installed on it.

- eu-west-1: ami-9fbfd6e8

- ap-southeast-1  ami-faf4f7a8

- ap-southeast-2 ami-4561297f 

- eu-central-1  ami-827d7c9f

- ap-northeast-1 ami-32ea7132 

- us-east-1 ami-79f3b01c 

- sa-east-1 ami-1d3aad00 

- us-west-1  ami-9d57bbd9

- us-west-2  ami-856365b5

[Jesse Yates]

For posterity, in case someone finds this later, the solution I came up with was to use the "vagrant ssh -c" flag to run a command inside the VM and then used the ability to run a command as a user (without switching) to start the services. So the external command was:
$ vagrant ssh -c '/home/vagrant/start-as-vagrant.sh'

And then that shell script (/home/vagrant/start-as-vagrant.sh) contained the one-liner:
$ sudo su root -c 'cd /vagrant/cloudbreak-deployment; cbd generate; cbd start'

where /vargrant/cloudbreak-deployment where I stored the vagrant generated profile.

So vagrant does work, just takes a little finagling. Would be nice to see the docker workarounds used so you can just use vagrant directly.