roboconf
Configure VMs for Roboconf agent with Dockerfiles
On many IaaS, we need to create a virtual image to install a Roboconf agent, then save the image, etc. On Docker, we have many parameters in the Docker target to generate a Dockerfile that will allow to create an image. On the embedded target (see #261), we also need to be able to configure existing machines by installing a JDK, a Roboconf agent, additional packages, custom extensions for the agent, etc.
Basically, many of these operations are similar. So, we need to have a library (packaged as a bundle) to group these operations. Besides, we should use a format that is getting a growing community. Dockerfile is the key. Keywords like RUN and COPY are what we need. Others will not make sense for most of our operations.
But from a Dockerfile, we could specify which packages to install, where, etc. So, we need a library that will...
- Parse a Dockerfile.
- Execute read instructions (those other than RUN and COPY should be ignored).
Example 1:
RUN apt-get update -y
RUN apt-get install roboconf-agent
COPY ext1.jar /usr/local/roboconf-agent/deploy
With one format, we can give instructions to execute on the system, provide resources and manipulate them, define and execute scripts, etc. It would replace parameters like docker.agent.package.url, docker.agent.jre-packages, docker.additional.deploy, etc. Obviously, we could have some custom placeholders to insert some values (such as the URL of the last snapshot agent). But most of the things would look regular from a Dockerpoint of view.
Such a library could then be used in...
- ... a SSH context (generating images on a IaaS, configuring an existing machine - embedded).
- ... a Docker context (replace many generation parameters by a Docker file).
This approach would be quite flexible, would adapt to various scenarios and would rely on a format that is simple and widely-used.
See https://docs.docker.com/reference/builder/ for the Dockerfile syntax.
It should be an interesting improvement to provide to Roboconf the capability to generate VM image for each supported target (Docker, Amazon, OpenStack, ...).
In fact, with this improvement, it will be no more needed to define the target in the application graph, only the Dockerfile file should be sufficient. When instantiating an application, we will chose the IaaS and the right image should be generating from the application dockerfile.
Perhaps, could we limit, in the application graph, the IaaS supported by the application.
Targets will remain necessary. Some parameters go beyond that what is on the VM. Some are related to API location and credentials, etc. This issue can only allow to generate images, which will be easier for users.
Sure, but I think these parameters are linked to the IaaS used, and they should be entered into the Roboconf console level, not at the application level.