I'd like to be able to define the variable values in DDEV's version-controlled ./ddev/config.yaml file, using the non-version-controlled .env file. For example (pseudo-code):
name: env($PROJECT_NAME)
# etc...
I can't rely on remembering to swap out config.yaml files or any other manual steps.
The reason for the season is that I need to have multiple DDEV instances of the same site. Each instance would be committing to the same repo, but may (or may NOT) have different branches. In other words, they need to be capable of being merged with each other, without DDEV getting mixed up. Since I have .ddev/config.yaml committed to the repo, I need some other way of having separate DDEV instances.
You probably want to use config.*.yaml for this. By default, config.*.yaml are gitignored. For example, config.local.yaml might have local overrides. See the docs for more info.
I haven't experimented with using the .env file in this context, but I know that config.local.yaml will work fine for this use.
Related
I have a complex project with multiple docker-compose files which get loaded depending on the environment I want to simulate.
I would like to see documentation related to the use of multiple compose files. I have the feeling that some sections are additive (ports) while other sections follow a replace strategy (environment)
I am unable to find documentation about this. Is there an official description of the behaviour?
I could prepare a simple PoC to test this, but I would prefer to refer to an official explanation to avoid reaching the wrong conclussions.
This is all I am able to find:
You can supply multiple -f configuration files. When you supply
multiple files, Compose combines them into a single configuration.
Compose builds the configuration in the order you supply the files.
Subsequent files override and add to their predecessors.
I read that "override and add to their predecessors" as meaning "some sections add, some sections override". I would like to know which ones add, and which ones override.
See the "Adding and overriding configuration" section of the "Extend services in Compose" page (emphasis in original):
For single-value options like image, command or mem_limit, the new value replaces the old value.
For the multi-value options ports, expose, external_links, dns, dns_search, and tmpfs, Compose concatenates both sets of values.
In the case of environment, labels, volumes, and devices, Compose “merges” entries together with locally-defined values taking precedence. For environment and labels, the environment variable or label name determines which value is used.
Entries for volumes and devices are merged using the mount path in the container.
That page also has several examples.
This matches the behavior you're observing: if you have two files that both have ports: they simply get concatenated together, but if you have two files that both have environment: variables, the last definition for each individual variable takes effect.
I need to use encryption on private/personal user data. I am going to use the following encryption library.
RbNaCL
I need a way to store the KEY outside of version control so I can run the app locally. When pushing the code to our hosting company I can put the KEY in the server env variables. Just not sure how and the best way to do it locally.
I should note that all developers working on the project use the same database so we all need the same KEY for development and staging environment.
https://www.happybearsoftware.com/how-to-actually-do-a-cryptography-in-ruby
I think what you are asking is how to keep a .env out of version control while in the repository, people collaborating should know about the what are the enviroment variables. Normally .env-sample (which is a dumy in which all variables are kept without values) is tracked and while .env is ignored (by adding it in .gitignore in case of git)
Typically, secrets never get committed to repositories. Just put them in a config file (like config.yaml or secrets.xml or env.sh or similar); copy the file (to something like config.yaml.example or secrets-skel.xml or env.sh.sample); put the first one into .gitignore (or equivalent, if you're a non-Git heretic), and replace all the secrets in the second one with placeholders. Commit the second one so that everyone who checks out the project will know the format that they should have; but the secret one never touches the repository. If you need to share keys between developers, do it in another way (from IRC/Slack/Email to encrypted USB storage device, depending on how confidential the stuff is).
If you go with YAML-ish kind of solution, in code you can try to find the file, if it is absent then use environment, or vice versa - look up environment, if no variable is there look for the config file to read from (and possibly even stuff it into ENV so you don't need another config object; you might do it in config/application.rb kind of thing. If you go with env.sh kind of approach, you can declare environment variables directly; when you need to start developing, you can source env.sh (or shorter . env.sh) to set them up.
I should note that all developers working on the project use the same database so we all need the same KEY for development and staging environment.
Store the key, and any other shared secrets, in a secure shared vault. Many password managers provide shared vaults, such as 1Password or LastPass.
Then each developer can copy the key from the shared vault and set it in their development environment.
How do you deal with host-specific configuration for docker containers?
Most importantly production passwords. They can't be put to container for security reasons. Also, they need to be changed on regular basis w/o redeploying anything.
I mostly use Volume containers if I really want to avoid making an image for that: http://docs.docker.com/userguide/dockervolumes/
however, I have done things like
FROM myapp
ADD password.file /etc
RUN do some cfg
to make specific images with password baked in.
That way the specific configuration list passwords is not in the general images which are re-used and known, but they are in an image that is build for and on the host that is running it. (this approach is not really very different to using puppet/chef etc to customise the files on a vm/server - it eventually needs to hit the filesystem in a safe, but repeatable way)
As one comment says, use environment variables you can pass via -e pass=abcdef. You can also save them in a fig.yml config file to avoid having to type them every time.
let's say I am developing 2 applications for 2 different clients which are, using 2 different database-configurations.
When using Openshift and CakePHP it is considered good practise to not store the real connection-info in the configs, but instead to use environment-variables.
That way the GIT-Repo is also always clean of server-specific stuff.
That is all fine as long as I have ONE project but as soon as there is another one, I need to override my local env-vars according to the current project.
Is there any way to avoid this? Is it possible to set up env-vars on my local machine per directory or something like that?
I am running OSX with Mamp Pro.
This may not be the best solution, but It would work. Create a different user on your local machine and then change to that other user when you need to access those other environment variables.
I create a 'data' directory in my git repo and set it to ignore. This way anything in there will be saved in the repo and sent to openshift. I place a config.ini file with all the info that I don't want in my repo.
I then manually put that config.ini file in Openshift's persistent DATA directory by using winSCP. You only have to do this when you change your config.ini.
When my app runs it detects if it's local or on Openshift and loads the config.ini file from the correct directory.
I would be interested if somebody has a better idea.
HTH
I am considering using Docker for a project, but I have one question I have not been able to find an answer to in the docs or anywhere else: is it possible to commit only a subset of the changes I make to an image?
Let's say I start a container, make a bunch of changes to the filesystem, get my thing working well and then want to commit them to a new base image. However, I only want a small subset of the changes that were actually made (maybe some of them were to log files, or other things that are unimportant). Does docker commit allow to specify that I only want changes, say, under some part of the filesystem to be committed?
You would just first remove the unnessecary files. To my knowledge, partial commits are not supported.
If you want to do this, using docker diff is really handy. You can easily see what the file system changes are that way. You can even run that against a running container.