Hi Ramon, On Thu, Mar 31, 2016 at 9:42 PM, Ramon Gordillo <[email protected]> wrote:
> Hi. > > After doing some research and test on the puppet modules and dockerfiles > with WSO2 API Management, I have some thoughts to share on this list. > > Great! It's really nice to hear you thoughts on $subject. > > Some particular information, for example the DNS domain name for the > cluster, the namespace, etc, is a runtime configuration. That is, if we > want, for example, to deploy an instance of api management per project (aka > namespace), with the current approach it will require to build a set of > docker containers per project. Currently, we have 10 teams working in their > own projects, so you can figure out the maintainability of 10 different > sets. > > It's not a must create a container image with all the required configuration. It's just a best practice. If the startup time of the server is not a problem, running an orchestration tool at the startup should be fine. We followed the same pattern few months back with Stratos + K8S. However I personally prefer fully configured container images approach as they are less error prone and may not depend on any dynamic parameters. It would be much similar to a product archive which includes all configurations, the person who deploys the product just need to extract and run. If there are any security concerns on the credentials and keys packaged, we might need to use a tool like secure wallet. > Apart from it, there are some configuration information that can be > obtained from the kubernetes master instead of hardcoding it in the > container. Even the kubernetes master information is injected in the > containers in environment variables ( > http://kubernetes.io/docs/user-guide/environment-guide/, see > KUBERNETES_SERVICE_HOST, KUBERNETES_SERVICE_PORT). > > With those considerations, I propose to use puppet also at runtime when > starting the container, for configuring it using template environment > variables (which are instanced at runtime), and getting as much information > as we could automatically instead of forcing the user to provide it. > Yes, as I mentioned above, it's a compromise between optimizing the startup time against the number of container images we need to maintain. > > Other than that, I also propose to have one script at startup per PaaS > solution. It will customize the peculiarities of this PaaS, and adapt it to > the agnostic configuration. For example, in kubernetes, some environment > variables are injected by default in the container, but in CloudFoundry, > for example, other variables with other structure is used. With this > approach, the container can be used for both of them (even with standalone > docker-compose for example) just having a simple and reusable script for > any PaaS solution. > AFAIU this would be only needed if we are to do configurations at the startup. If the container image contains all configurations needed we may not need a PaaS specific startup script. Thanks > What do you think? > > Thanks. > > Regards. > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- *Imesh Gunaratne* Senior Technical Lead WSO2 Inc: http://wso2.com T: +94 11 214 5345 M: +94 77 374 2057 W: http://imesh.io Lean . Enterprise . Middleware
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
