Going through Part 3 tutorial of Docker's Getting Started.
I was able to run the load balanced app with 5 instances using the below command
$ docker stack deploy -c docker-compose.yml getstartedlab
top-level network "webnet" is ignored
service "web": network "webnet" is ignored
Waiting for the stack to be stable and running...
web: Ready [pod status: 5/5 ready, 0/5 pending, 0/5 failed]
But, when I try to list the services with command docker service ls it does not show any data.
$ docker service ls
ID NAME MODE REPLICAS IMAGE PORTS
Am I doing something wrong here. Could anyone please guide me?
It looks like you're using Kubernetes instead of Swarm as the orchestrator. In the current implementation, you can only get the services for a specific stack, not list all services.
docker stack services getstartedlab
Perhaps you didn't mean to use Kubernetes as the stack orchestrator? You can disable it by going the Docker menu → Preferences… → Kubernetes, and unchecking “Enable Kubernetes”.
Related
This question already has answers here:
Docker container will automatically stop after "docker run -d"
(22 answers)
Closed 10 days ago.
Given this simple Docker compose.yaml file:
services:
test:
image: node:18
website:
image: nginx
After running:
docker compose up
docker ps
I expected to see two running containers/images. Instead I got just the one:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c970ef47fb93 nginx "/docker-entrypoint.…" 51 seconds ago Up 48 seconds 80/tcp myid-website-1
What is happening here? Does Docker expect that a persistent process is kept running within the container image? How does it decide which services persist?
I also noticed that adding restart: always caused the Node image to perpetually restart. What would be a good way to get the Node image to start via Docker Compose, such that I could log into it via docker exec?
My instinct is that this has to do with the distinction between services and images/containers.
For a container to persist, it needs to run a program. When the program ends, the container is stopped.
The Nginx image runs the command nginx -g daemon off; which starts Nginx and then waits for requests to come in. It doesn't end.
The Node image runs the command node. When there's no arguments passed to it, it runs in interactive mode. But when you run it like you do, there's no TTY attached to the container, so node sees that there's no way to get any input. So node exits and the container is stopped.
If you run the command docker ps -a, you'll also see stopped containers. You'll then see that your node container has exited.
I have a single-node swarm. My stack has two services. I deployed like so:
$ docker stack deploy -c /tmp/docker-compose.yml -c /tmp/docker-compose-prod.yml ide-controller"
Creating network ide-controller_default
Creating service ide-controller_app
Creating service ide-controller_traefik
No errors. However, according to docker ps, only one container is created. The ide-controller_traefik container was not created.
When I check docker stack services, it says 0/1 for the traefik container:
ID NAME MODE REPLICAS IMAGE PORTS
az4n6brex4zi ide-controller_app replicated 1/1 boldidea.azurecr.io/ide/controller:latest
1qp623hi431e ide-controller_traefik replicated 0/1 traefik:2.3.6 *:80->80/tcp, *:443->443/tcp
Docker service logs has nothing:
$ docker service logs ide-controller_traefik -n 1000
$
There are no traefik containers in docker ps -a, so I can't check logs:
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
922fdff58c25 boldidea.azurecr.io/ide/controller:latest "docker-entrypoint.s…" 3 minutes ago Up 3 minutes 3000/tcp ide-controller_app.1.py8jrtmufgsf3inhqxfgkzpep
How can I find out what went wrong or what is preventing the container from being created?
docker service ps <service-name/id> has an error column that can expose errors encountered by libswarm trying to create containers, such as bad image names.
Or, for a more detailed look, docker service inspect <service-name/id> has the current, and previous, service spec, as well as some root level nodes that will trace the state of the last operation and its message.
I am following this tutorial Build Your First Network to build my first fabric network. After executing ./byfn.sh -m up, everything looks fine. But When I check environment variables, it mentioned CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin#org1.example.com/msp
. But this crypto does not exist in /hyperledger/fabric/peer/ path. What's wrong?
I am not sure if you are checking it inside the cli container. Note that a volume mapping between the container named "cli" and your host machine is defined under the file docker-compose-cli.yaml, you can have a look here for the information https://github.com/hyperledger/fabric-samples/blob/release-1.2/first-network/docker-compose-cli.yaml#L83. When you issue a command docker exec -it cli bash to enter the container named cli, you should be able to find the path.
You are right that there is no folder as crypto in the /hyperledger/fabric/peer/ assuming that you were seeking in the peer of org1 container (e.g. docker exec -it peer0.org1.example.com) or other peer containers.
The reason is due to the fact that Environment variables are set in the cli container and its uses fabric-tools image not fabric-peer
image while orchestration. This setup is seen only in first network of fabric samples. While the cli makes install, instantiate, query, etc. commands it changes the Environment variables to act as peer before sending those commands.
So, crypto material will be in the cli container (docker exec -it cli bash). You can see the volume mapping of containers and specifically cli container for which container the crypto material is mapped in dockercompose-cli.yaml, base/docker-compose-base.yaml and base/peer-base.yaml files.
NOTE:
"first network" or "Build Your First Network" is for only testing and learning purposes not for production.
References:
[1] : Building Your First Network (https://hyperledger-fabric.readthedocs.io/en/release-1.2/build_network.html?highlight=fabric-tools)
I am trying out docker swarm with 1.12 on my Mac. I started 3 VirtualBox VMs, created a swarm cluster of 3 all fine.
docker#redis1:~$ docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
2h1m8equ5w5beetbq3go56ebl redis3 Ready Active
8xubu8g7pzjvo34qdtqxeqjlj redis2 Ready Active Reachable
cbi0lyekxmp0o09j5hx48u7vm * redis1 Ready Active Leader
However, when I create a service, I see no errors yet replicas always displays 0/1:
docker#redis1:~$ docker service create --replicas 1 --name hello ubuntu:latest /bin/bash
76kvrcvnz6kdhsmzmug6jgnjv
docker#redis1:~$ docker service ls
ID NAME REPLICAS IMAGE COMMAND
76kvrcvnz6kd hello 0/1 ubuntu:latest /bin/bash
docker#redis1:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
What could be the problem? Where do I look for logs?
Thanks!
The problem is that your tasks (calling bin/bash) exits quickly since it's not doing anything.
If you look at the tasks for your service, you'll see that one is started and then shutdown within seconds. Another one is then started, shutdown and so on, since you're requested that 1 task be running at all times.
docker service ps hello
If you use ubuntu:latest top for instance, the task will stay up running.
This also can happen if you specify a volume in your compose file that is bound to a local directory that does not exist.
If you look at the log (on some Linux systems, this is journalctl -xe), you'll see which volume can't be bound.
In my case, the replicas were not working and a 0/0 was shown as I did not build them before.
As I saw here, when u publish to swarm with a
docker-compose.yml you need to build them before
So, I decided to do a full system prune, and next to it, a build and a deploy (here, my stack was called demo and I did not have previous services or containers running):
docker stack rm demo
docker system prune --all
docker-compose build
docker stack deploy -c ./docker-compose.yml demo
After this, all was up and running and now services replicas are up on swarm
PS C:\Users\Alejandro\demo> docker service ls
ID NAME MODE REPLICAS IMAGE PORTS
oi0ngcmv0v29 demo_appweb replicated 2/2 webapp:1.0 *:80->4200/tcp
ahuyj0idz5tv demo_express replicated 2/2 backend:1.0 *:3000->3000/tcp
fll3m9p6qyof demo_fileinspector replicated 1/1 fileinspector:1.0 *:8080->8080/tcp
The way I maintain the replicas working, at the moment, in dev mode:
Angular/CLi app:
command: >
bash -c "npm install && ng serve --host 0.0.0.0 --port 4200"
NodeJS Backend (Express)
command: >
bash -c "npm install && set DEBUG=myapp:* & npm start --host 0.0.0.0 --port 3000"
I'm playing around now with docker 1.12, created a service and noticed there is a stage of "preparing" when I ran "docker service tasks xxx".
I can only guess that on this stage the images are being pulled or updated.
My question is: how can I see the logs for this stage? Or more generally: how can I see the logs for docker service tasks?
I have been using docker-machine for emulating different "hosts" in my development environment.
This is what I did to figure out what was going on during this "Preparing" phase for my services:
docker service ps <serviceName>
You should see the nodes (machines) where your service was scheduled to run. Here you'll see the "Preparing" message.
Use docker-machine ssh to connect to a particular machine:
docker-machine ssh <nameOfNode/Machine>
Your prompt will change. You are now inside another machine.
Inside this other machine do this:
tail -f /var/log/docker.log
You'll see the "daemon" log for that machine.
There you'll see if that particular daemon is doing the "pull" or what's is doing as part of the service preparation.
In my case, I found something like this:
time="2016-09-05T19:04:07.881790998Z" level=debug msg="pull progress map[progress:[===========================================> ] 112.4 MB/130.2 MB status:Downloading
Which made me realise that it was just downloading some images from my docker account.
Your assumption (about pulling during preparation) is correct.
There is no log command yet for tasks, but you could certainly connect to that daemon and do docker logs in the regular way.