We have a fairly complex system using docker-compose with a lot of different microservices. I want to be able to run an individual microservice via visual studio with one docker-compose configuration (Debug). Alternatively, I have another configuration (lets call it Debug2) where I want a slightly different docker-compose configuration.
Right now my "docker-compose.yml" file has the basics, and my "docker-compose.override.yml" has some development specific things. I made a "docker-compose.debug.yml". When I run the project in Debug mode, it launches all 3 of those files.
All is well so far, right?
Well, then I tried making a "docker-compose.debug2.yml". I added a new configuration to the project and solution called "Debug2". When I try running from Visual Studio in that mode, it only launches with the first 2 files, and doesn't attempt to use the "debug2" file at all.
Is the system hardcoded to only allow Debug and Release override files? Did I do something wrong or is there an oversight? Any other ideas?
When you are running the services via compose, are you passing the optional override file as well?
For example,
docker-compose -f docker-compose.debug.yml -f docker-compose.debug2.yml
By default, compose only looks for a docker-compose.overrides.yml to my knowledge. Therefore, you would have to pass it as an optional argument when you spin up your environment.
"By default, Compose reads two files, a docker-compose.yml and an optional docker-compose.override.yml file. By convention, the docker-compose.yml contains your base configuration. The override file, as its name implies, can contain configuration overrides for existing services or entirely new services."
For more information: https://docs.docker.com/compose/extends/
For anyone else coming across this issue you can find documentation here:
https://learn.microsoft.com/en-us/visualstudio/containers/docker-compose-properties?view=vs-2019
The two specific file names for "debug" and "release" are:
docker-compose.vs.debug.yml
docker-compose.vs.release.yml
Related
I have 2 .properties files for my project on hybris .
First one is used for CI process and as a result a got 4 zip files with my already built platform(after ant production).
On my prod instance i need to switch to another properties because there are all my connections to extended services such as mysql solr.. etc
How i can do that without running all ANT steps.
. ./setantenv.sh && sync && ant config -Denv=my_new_properties
then ./hybrisserver.sh start doesn't work.
There is no information on wiki https://cxwiki.sap.com/display/release5/ant+production+improvements
Check if Updating Configuration Settings at Runtime will be useful for you. You will need to use the FileBasedConfigLoader class and the runtime.config.file.path property.
Other best practices include using system variables for secure settings like DB URL. See "Using Environment Variables instead of Files for Secure Settings" section in Configuring the Behavior of SAP Commerce.
Another option you can look at is to have different config folders for different environments (e.g. config-dev, config-prd), and pass it to ant. e..g -Denv=config--dev
Visual Studio Code (1.22.2) offers a file extension named .dockerfile in the the save dialog. What is a file with this extension? A Dockerfile is in all documentation and examples, that I've seen so far, only called Dockerfile.
If I enter Dockerfile as a file name, a file named Dockerfile.dockerfile is created.
It appears that "*.dockerfile" is simply an alternative to the conventional "Dockerfile" name. This is perhaps useful if you want to keep a collection of dockerfiles in the same directory. Note the -f/--file option in docker help build:
-f, --file string Name of the Dockerfile (Default is 'PATH/Dockerfile')
In other words, you are not required to use the name "Dockerfile", and the VSCode extension will correctly syntax-highlight any file ending in ".dockerfile".
Dockerfile
A Dockerfile is a text document that contains all the commands a user could call on the command line to assemble an image. Using docker build users can create an automated build that executes several command-line instructions in succession. Docker images are the basis of containers. An Image is an ordered collection of root filesystem changes and the corresponding execution parameters for use within a container runtime. An image typically contains a union of layered filesystems stacked on top of each other. An image does not have state and it never changes.More on
Dockerfile extension
A Dockerfile has no extension . if your using docker on docker on windows use notepad ++ to create a dockerfile while saving select “All type “ and save the file name as “Dockerfile”.
Mongodb/Dockerfile
Using the .dockerfile extension tells VSCode that the file is a DockerFile for code highlighting and linting
What worked for me was to save the file in VS Code as a Dockerfile. But, you need to remove the .dockerfile extension that VS Code puts on it before running the $docker-compose up command:
Even though VSCode can deal with extensionless files just fine, some major parts of the Windows operating system can't. Try double clicking a Dockerfile (without extension) in the Windows Explorer. You will always be asked which program you want to open it in because Windows can't map extensionless files to a default program.
My guess is that because of this problem, Microsoft would like for all files to have an extension and uses VSCode to nudge people towards using a file extension for Dockerfiles, ignoring the fact that this contradicts the de facto standard.
Dockerfile doesn't have any extensions.
As you can see from hte documentation, https://docs.docker.com/compose/gettingstarted/, it doesn't have any extensions.
When using the integrated docker-compose structure in Visual Studio 2017, the system provides visibility to a two-tiered docker-compose structure.
docker-compose.yml and docker-compose.override.yml
Settings in the override take precedent over those in the former file. When the file is actually executed, it includes a third, auto-generated Docker compose file ...
docker-compose.vs.*configuration*.g.yml
This latter file contains mostly values related to debugging interactions and mapping volumes in for code you want. Generally, you wouldn't want to change any of these.
One thing that it does by default is to set the entrypoint which ends up becoming the command for the container. As this file is applied last (after the compose file and the override, it is holding precedence over the other two resulting in not being able to override that entrypoint.
Is there a way around this?
I have a lot of services, which use the same basic configuration in docker-compose. Actually most of the configuration is the same, with some minor tweaks.
I have seen that it is somehow possible to inherit values in YAML. Can I use this in docker-compose to define a "default-service" and use this all over in the other services for e.g. docker-compose run? How would I do this?
No, you cannot do that using YAML. The only inheritance like feature in YAML is the Merge Key Language Independent Type and that only works withing one YAML document, not between multiple documents in the same YAML file (separated by ---) and certainly not between different YAML files.
However docker-compose reads docker-compose.yml and if available docker-compose.override.yml, where the values in the second file (if available) override the ones in the first. Combined with the -f option to specify an input YAML file for docker-compose you can use a shared base file with different overrides.
This is a feature of docker-compose and is done on the data loaded from the YAML files, not by combining the YAML files and then loading them.
Suppose I have a Grails application named myCoolApp.
Furthermore, suppose I have defined some basic properties in grails-app/conf/Config.groovy and grails-app/conf/DataSource.groovy under the test and production profiles.
Config.groovy is set to merge with the following .groovy external configuration file, if found at all:
grails.config.locations = ["file:${userHome}/.grails/${appName}-config.groovy"]
Finally, I have also defined, inside an external testing server, such a file, under a local *NIX user path:
/home/appServerTestUser/.grails/myCoolApp-config.groovy
Sadly, I find that for some reason, the external .groovy file's properties are not being merged when a Tomcat instance starts up.
What options do I have to make Grails tell me: "Oh, yes, I found your external config file at: /home/appServerTestUser/.grails/myCoolApp-config.groovy" and these are the properties I merged into Config.groovy?
Thanks!
File-based paths don't make much sense in a deployed app. It could work when deploying on your dev machine for testing, but will likely fail on any other machine. And it'll probably fail locally even if configured with the correct path since the process will like run as a different low-priviledge user.
You can use absolute paths, e.g. /etc/myapp/path/to/file, but this tends to couple deployment to filesystem structure, so if you develop in Windows and deploy on Linux it'd be tricky to get them both working.
So the best bet for Tomcat deployment is to use the classpath syntax. You can specify multiple files and it will load all that it finds, so I usually have one entry for local dev and one for the deployed app:
grails.config.locations = [
"classpath:${appName}-config.groovy",
"file:./${appName}-config.groovy"
]
I delete the entries for .properties files because Groovy syntax is so much more flexible, but use them if you like. I also keep the dev files in the project root (and exclude from source control).
So when deploying, name the file correctly (different apps will have different files, so no clashing there) and put them in Tomcat's lib directory. This is in the classpath, and so the classpath: entry will see it.