So, i have a docker-compose file that has a build command in each service. In development, docker-compose up works ok. In test enviroment, i want to docker-compose pull and docker-compose build the images, and it works ok, except it needs the folder in build command created in testing server.
Is it really necesary or is there a way to pull and up the containers without create the build folders in the testing server?
There is docker-compose up --no-build
Related
I am trying to build and deploy asp net core container app to heroku app using Github Actions. Due to some reason i am getting COPY failed error. Same DockerFile is working fine in my local.
Please find my docker file and github actions below.
Docker File, Workflow File, Action Logs
The path you specified for .csproj is incorrect based on your github action workflow.
However, without making any further changes to the Dockerfile, if you change your Github Action workflow by setting the correct working-directory: src & dockerfile: 'Services/Core/MyFamilyManager.API/', it will fix your problem.
Looks like there is no way to make it work with my solution folder structure. docker always uses DockerFile folder as context, so it will not be able to access my other parent folders.
I found a way by creating docker compose file at my root of my solution to build container image.
I have created and published Github action. I hope this will help others with similar issue.
https://github.com/marketplace/actions/deploy-multiple-docker-images-to-heroku-apps
I'm trying to use codeship to automate building docs from a repository.
After the Executing the command mkdocs build --clean I get a path to where my site folder is supposed to be.
INFO - Cleaning site directory
INFO - Building documentation to directory: /home/rof/src/bitbucket.org/josephkobti/test/site
The thing is that I can't find that folder using the ssh console for debugging.
The reason for the folder not existing was a misunderstanding of Codeship's SSH Debug Build feature, documented here https://documentation.codeship.com/basic/builds-and-configuration/ssh-access/
The VMs started for the debug feature are not the actual VMs that run the automated builds. They are new VMs running the same initialization steps as the automated builds (i.e. cloning the repository, configuring project specific environment variables, ...) but none of the actual setup or test commands.
Because of this the mkdocs build --clean command wasn't run either when Joseph connected via to the debug VM, and as such the generated site wasn't available.
My application has 4 docker containers that talk to each other and is specified with a docker-compose.yml file, so I can just do docker-compose up -d from the location where that file is stored and it starts.
I am virtually the end of setting up my CI service to go from commit to the git repository to testing and then building the docker images that I need for my deploy. I now need to sort out how to deploy.
I already have the current version running, and my docker-compose.yml file is configured via environment variables held in a .env file. It is unlikely that it will change between versions, but it might. What will change is the .env file, as that specifies image names and tags that the CI system has just build and which the docker-compose.yml file will use to start the new version of the running system. .env is created on the fly by scripts in the repository and is run by the CI system in its workspace. My deploy step is really just about copying .env and docker-compose.yml into place and then stopping the old set of services and starting the new.
My question is, if I change the .env file or docker-compose.yml under a running version, will docker-compose down properly stop the old running images, so that when I immediately follow it with a docker-compose up -d I swap over to the new images. Is there a better way of handling this situation
I've put a Dockerfile in the root directory of my project. I know the Dockerfile works because I've built it locally. But when I try to build it in the pipeline, it says Dockerfile not found in project and aborts.
The documentation indicates that it should work so long as the Dockerfile is in the root directory. So I'm really confused.
do I need to supply some additional information in the build job to point it do the Dockerfile?
Thanks.
I'm trying to figure out the best way to ignore some folders and files from my Codeship deployment process. At the moment it compiles all my assets as part of the deployment process but I don't really want it uploading node_modules to the server.
Is there a way to ignore the folder or remove the folder before deployment?
I tried deleting it after I ran grunt but I think it gets cached as it didn't work.
The method I used was to rm -r YOUR_PATH/node_modules in the test pipeline after Grunt has been run.
This however seemed to have some issues when running on FTP deploy. For any of the SSH deploys it seems to work fine.