3 ms·

How do you handle different configurations then? Especially if you need to provide N values (or structured data). Also, how do you manage your containers in pr

by odiroot 11y ago

How do you handle different configurations then? Especially if you need to provide N values (or structured data). Also, how do you manage your containers in production?

omarforgotpwd 11y ago
I use environment variables, which can be passed in as arguments when you start the container. In cases where the configuration is complicated I'll use an environment variable to tell the container which redis key / db key to load config from.
grhmc 11y ago
Configuration: We use environment variables for anything small-ish. For more complicated configurations, similar to omarforgotpwd, we keep the values (files AND environment variables) in S3 and download them at deploy time. For stage/prod differences we can literally diff the different S3 buckets. Management: We create AMIs using Packer. Packer runs a provisioning tool which downloads tho container and the configuration and sets up the process monitoring. It then builds a machine image, and then we launch new servers.
mark_round 11y ago
As others have written, you can either download your config from an external host, or pass in environment variables to your container and generate a configuration based on them. Lots of people write their own scripts to do this; I wrote Tiller (http://github.com/markround/tiller http://github.com/markround/tiller) to standardise this usage pattern. While I have written a plugin to support storing values in a Zookeeper cluster, I tend to prefer to keep things in YAML files inside the container - at least, for small environments that don't change often. It just reduces a dependency on an external service, but I can see how useful it would be in larger, dynamic environments.
falcolas 11y ago
Configuration files, made available to containers as a read-only mount via the volume flag. No external network or service dependencies that way. I'm not terribly fond of using environment variables for configuration, personally. That method requires either a startup shim or development work to make your program aware of the variables, and your container manager has to have access to all configuration values for the services it starts up.

by odiroot 11y ago

How do you handle different configurations then? Especially if you need to provide N values (or structured data). Also, how do you manage your containers in production?

omarforgotpwd 11y ago

I use environment variables, which can be passed in as arguments when you start the container. In cases where the configuration is complicated I'll use an environment variable to tell the container which redis key / db key to load config from.

grhmc 11y ago

Configuration: We use environment variables for anything small-ish. For more complicated configurations, similar to omarforgotpwd, we keep the values (files AND environment variables) in S3 and download them at deploy time. For stage/prod differences we can literally diff the different S3 buckets. Management: We create AMIs using Packer. Packer runs a provisioning tool which downloads tho container and the configuration and sets up the process monitoring. It then builds a machine image, and then we launch new servers.

mark_round 11y ago

As others have written, you can either download your config from an external host, or pass in environment variables to your container and generate a configuration based on them. Lots of people write their own scripts to do this; I wrote Tiller (http://github.com/markround/tiller http://github.com/markround/tiller) to standardise this usage pattern. While I have written a plugin to support storing values in a Zookeeper cluster, I tend to prefer to keep things in YAML files inside the container - at least, for small environments that don't change often. It just reduces a dependency on an external service, but I can see how useful it would be in larger, dynamic environments.

falcolas 11y ago

Configuration files, made available to containers as a read-only mount via the volume flag. No external network or service dependencies that way. I'm not terribly fond of using environment variables for configuration, personally. That method requires either a startup shim or development work to make your program aware of the variables, and your container manager has to have access to all configuration values for the services it starts up.