After upgrading my docker desktop, I get an error when running docker-compose up. My usual setup consists of microservices controlled with the docker-compose command. When I run docker-compose up, all the containers are started. After updating my docker desktop, I get:
Can't separate key from value
while running docker-compose up. How do I fix this?
Check for the version number of docker and if its 3.4+ then the docker compose v2 is enabled by default. To disable it, go to > docker desktop > preferences > experimental features > un-check "use Docker Compose V2" option. This is a move by docker hub to incorporate docker-compose as docker compose and may cause problems to your usual workflow. Enjoy :)
Just in case if anyone else (like me) run into this issue:
Check the local (to docker-compose.yaml) .env file, is there a VARIABLE without mapping? If so... remove it or give it a value...
More specifically maybe:
MY_VAR= // works fine
MY_VAR2 // fails
; MY VAR // also fails
; MY_VAR= // works, but fails later with an actually useful msg
Related
I want to make my testcontainers in Java integration tests work with minikube replacing Docker Desktop.
I followed below article to get started:
https://www.atomicjar.com/2021/10/docker-on-windows-and-macos/#minikube
This is what I've got in testcontainers.properties
docker.client.strategy=org.testcontainers.dockerclient.EnvironmentAndSystemPropertyClientProviderStrategy
docker.host=tcp\://192.168.64.2\:2376
docker.cert.path=/Users/username/.minikube/certs
docker.tls.verify=true
Although my docker is up and running, I'm getting following exception:
Caused by: java.lang.IllegalStateException: Could not find a valid Docker environment. Please see logs and check configuration
Can anybody please suggest anything to make it working?
TA
If you are using gradle try -no-daemon flag to use a new daemon. Your old gradle daemon still using your previous testcontainers properties, also restart your IDE if you're running your build inside.
After restarting Minikube and Intellij editor, and updating testcontainer-bom to be the latest - from 1.15 to 1.16.2, I was able to pull some third-party docker images. This means docker is working now.
However, I'm still trying to find a way to work with local images (Other application docker images) for integration testing as it used to work with Docker Desktop.
So, I ran a docker image with certain settings a while ago. In the meantime I updated my container settings via "docker update".
Now I want to see, what options/configurations (e.g. cpuset, stack, swap) are currently configured for my container.
Is there a docker command to check this?
If not, (why the hell isn't there and) where exactly can I find this information?
I am running docker 18.03.1-ce on debian 9.4.
Greetings,
Johannes
I found it out by myself.
To get detailed information about a containers settings one can use:
docker inspect 'options' 'containerid'
Can be closed, not sure how to do it.
I am to be quite frank lost right now, the user whom published his source on github somehow failed to update the installation instructions when he released a new branch. Now, I am not dense, just uneducated when it comes to docker. I would really appreciate a push in the right direction. If I am missing any information from this post, please allow me to provide it in the comments.
Current Setup
O/S - Debian 8 Minimal (Latest kernel)
Hardware - 1GB VPS (KVM)
Docker - Installed with Compose (# docker info)
I am attempting to setup this (https://github.com/pboehm/ddns/tree/docker_and_rework), first I should clone this git to my working directory? Lets say /home for example. I will run the following command;
git clone -b docker_and_rework https://github.com/pboehm/ddns.git
Which has successfully cloned the source files into /home/ddns/... (working dir)
Now I believe I am supposed to go ahead and build something*, so I go into the following directory;
/home/ddns/docker
Inside contains a docker-compose.yml file, I am not sure what this does but by looking at it, it appears to be sending a bunch of instructions which I can only presume is to do with actually deploying or building the whole container/image or magical thing right? From here I go ahead and do the following;
docker-compose build
As we can see, I believe its building the container or image or whatever its called, you get my point (here). After a short while, that completes and we can see the following (docker images running). Which is correct, I see all of the dependencies in there, but things like;
go version
It does not show as a command, so I presume I need to run it inside the container maybe? If so I dont have a clue how, I need to run 'ddns.go' which is inside /home/ddns, the execution command is;
ddns --soa_fqdn=dns.stealthy.pro --domain=d.stealthy.pro backend
I am also curious why the front end web page is not showing? There should be a page like this;
http://ddns.pboehm.org/
But again, I believe there is some more to do I just do not know what??
docker-compose build will only build the images.
You need to run this. It will build and run them.
docker-compose up -d
The -d option runs containers in the background
To check if it's running after docker-compose up
docker-compose ps
It will show what is running and what ports are exposed from the container.
Usually you can access services from your localhost
If you want to have a look inside the container
docker-compose exec SERVICE /bin/bash
Where SERVICE is the name of the service in docker-compose.yml
The instructions it runs that you probably care about are in the Dockerfile, which for that repo is in the docker/ddns/ directory. What you're missing is that Dockerfile creates an image, which is a template to create an instance. Every time you docker run you'll create a new instance from the image. docker run docker_ddns go version will create a new instance of the image, run go version and output it, then die. Running long running processes like the docker_ddns-web image probably does will run the process until something kills that process. The reason you can't see the web page is probably because you haven't run docker-compose up yet, which will create linked instances of all of the docker images specified in the docker-compose.yml file. Hope this helps
My root problem is that I need to support a local docker registry, self-signed certs and whatnot, and after upgrading to Docker for Mac, I haven't quite been able to figure out how to pass in options, or persist options, in the docker/alpine image running via the new and shiny xhyve that got installed with Docker for Mac.
I do have the functional piece of my problem solved, but it's very manual:
screen ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/tty
log in as root
vi /etc/init.d/docker
Append --insecure-registry foo.local.machine:5000 to DOCKER_OPTS; write file; quit vi.
/etc/init.d/docker restart
Now, if from the perspective of the main OS / OSX, Docker is restarted -- like a simple reboot of the computer -- of course this change and option is lost, and I have to go through this process again.
So, what can I do to automate this?
Am I missing where DOCKER_OPTS may be set? The /etc/init.d/docker file, internally, doesn't overwrite the env var, it appends to it, so this seems like it should be possible.
Am I missing where files may be persisted in the new docker image? I admit I'm not as familiar with it than the older image that I believe was boot2docker based, where I could have a persisted volume attached, and an entry point where to start these modifications.
Thank you for any help, assistance, and inspiration.
Go to Docker preferences (you can find icon on main panel)
Advanced -> Insecure docker registry
Advanced settings pictures
I wonder how if it's oK for using tuleap docker container as production site?
is it as safe and stable as full installtion?
What's the best way to start it to make it more like a true server and easy to backup any change to host's volume?
TL;DR: yes but not with docker run -d enalean/tuleap-aio
You can run it in production using docker but you should better be good at both Tuleap AND docker (esp. docker in production FWIW).
The default image (tuleap-aio) is rather designed for a test purpose and there is not volume management attached neither security upgrades.
If you want to do docker + tuleap in prod you will have to:
be confident with docker in production itself
be able to build your own tuleap image (with the list of plugin you want, your config & etc)
be able to manage data volume for application and DB
Docker is stable and safe; it's just a matter of figuring out how to use it. You're going to want to look up the Compose File reference and set up the correct volumes, which requires an understanding of the application and its packaging in the container.
You can see this Link
http://tracker.restlessdev.com/doc/en/developer-guide/quick-start/run-tuleap.html
This is the best way to have tuleap running in a docker container , the other way is just for testing without modify the source code of tuleap.