Hi Hitesh, Yes, starting different components in respective containers is an ideal approach. The PR link contains a README which explains how to build individual images for different components. The Dockerfile has been abstracted to take the component name as a parameter during “docker build –t <component>”.
Regarding the configurations, you can also try leveraging Docker environment variables during docker container startup, and similarly link containers to achieve component-to-component communication using a hostname. I agree it’s not the best approach, because in the long run when we scale containers and add High Availability, we will need to add service level load-balancers. The good news though, performing container linking and referencing components using hostnames (a.k.a service names), will allow us to fully exploit default load balancing features provided by nearly all orchestration frameworks such as Kubernetes, DC/OS, Swarm, etc. Let me know if you need help. Thanks and Regards, Gourav Shenoy From: Hitesh Kumar Dasika <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Saturday, September 30, 2017 at 2:24 PM To: "[email protected]" <[email protected]> Subject: [FALL-2017] Dockerizing Airavata PGA 2. The second thing is default configurations which need to be copied. There are many conf files and there are placeholders in those which are replaced by ansible. Whereas in Docker container creation, such configurations need to be copied without placeholders into the containers. To achieve this, my plan is to include a volume which is mounted to the container and that volume will have all the configuration files in it. The user will have the option to change configurations in those files. Any Suggestions would be appreciated. @Gourav The PR contains a single dockerfile for all the services. But won't it be good if there are different containers with different components in them? This approach will also be helpful for orchestration Regards Hitesh Kumar Dasika
