Replace puppet 'docker' with containers

[jeff1evesque]

Our intention with our docker containers, was to use them for unit testing our application as a whole, while testing the validity of the puppet scripts, used to build our development environment. However, this basis is not really valid, since we implement the docker puppet environment, which is beginning to change from the vagrant environment. This means, our docker containers are no longer checking the validity of puppet logic, used to build our development environment. And since the requirements of docker, and vagrant is not always a one-to-one relationship, we won't always be able to reuse the exact puppet script(s) between the vagrant and docker puppet environments.

Additionally, running puppet in docker, is similarly flawed to #2932. Therefore, we will eliminate our puppet implementation, within our docker containers, used for unit testing. This means we'll remove entirely the docker puppet environment, create an equal number of dockerfile's, as the number of puppet modules defined in our vagrant puppet environment, and adjust our .travis.yml, respectively.

[jeff1evesque]

We'll need to decide whether to write custom python scripts, or RUN bash commands which parse our current settings.yaml, and packages.yaml, and reference corresponding attributes.

[jeff1evesque]

Another supporting fact regarding the divergence between two puppet environments, was the requirement of installing nodejs from a 4.x repository for the docker environment, while the vagrant environment was able to remain the same, using the 5.x repository.

[jeff1evesque]

We'll look into replacing vagrant with rancher's integration with docker swarm.

[jeff1evesque]

We need to look into implementing rancher compose, configuration files.

[jeff1evesque]

We may need not need cygwin. However, all distro's will need wget, to successfully run our current install_rancher script. Therefore, we may need to adjust our language in our current README.md.

[jeff1evesque]

In order for our current reverse_proxy puppet module to execute, we need to have the container's hostname defined during build time, or during the RUN directive, implementing the puppet apply. Having the hostname defined, would allow the puppet module to implement the hiera definition, contained within the copied nginx-xxx.yaml configuration. Otherwise, we'll need to refactor our nginx.dockerfile into nginx-web.dockerfile, and nginx-api.dockerfile. This would mean the corresponding COPY statements would need to be refactored, to copy only the required nginx-xxx.yaml, into the nginx-xxx container. Then, the hiera.yaml would need to become more verbose (not preferred), or we could dynamically copy the needed yaml configuration, as a fixed nginx.yaml, in each nginx-xxx container, while changing path: "hiera/webserver/%{::hostname}.yaml" to path: "hiera/webserver/nginx.yaml", in our hiera.yaml.

[jeff1evesque]

Trying to append to the /etc/hosts is not successful:

Step 16/16 : RUN echo $(head -1 /etc/hosts | cut -f1) 'nginx-web' >> /etc/hosts && echo "hostname: $(hostname)"
 ---> Running in 8519bccb1d13
hostname: 8519bccb1d13

Additionally, running the hostname command directly fails:

Step 16/16 : RUN echo $(head -1 /etc/hosts | cut -f1) nginx-web >> /etc/hosts && echo "hostname: $(hostname)" && hostname nginx-web && echo "hostname2: $(hostname)"
 ---> Running in 8873d524abba
hostname: you must be root to change the host name

[jeff1evesque]

So, we attempted to force docker to use the root user (should be the default behavior):

Step 16/17 : USER root
 ---> Running in 98460e35d31b
Removing intermediate container 98460e35d31b
 ---> 6356bba11f3e
Step 17/17 : RUN echo $(head -1 /etc/hosts | cut -f1) 'nginx-web' >> /etc/hosts && echo "hostname: $(hostname)" && hostname 'nginx-web' && echo "hostname2: $(hostname)"
 ---> Running in 212d6261fb7c
hostname: you must be root to change the host name

Note: another option we have, in addition to those discussed above, is to possibly run the puppet provisioning during an ENTRYPOINT. However, this seems a bit of a cumbersome step, since building should be during build run phase.

[jeff1evesque]

We are able to confirm that our current configurations, within our nginx-web container, could access the webserver-web container on port 5001:

Therefore, we need to verify if our nginx configurations, specifically the upstream is properly defined.

[jeff1evesque]

Our nginx-webserver seems to behave as expected, since we no longer experiencing an nginx 405 error, in the browser . However, it may be likely that our compiled content.js, is not properly implementing our anticipated nodejs presets, or modules, during the attempt to transform, and compile .jsx to .js: