I would like to set up a Iroha Network consisting of 3 nodes on one host using docker containers. Therefore I have set up 3 postgres containers, 3 blockstores and one iroha-network.
Starting the different postgres containers works fine (mapped on the ports 5532, 5533, 5534). And the first iroha containers also seems to be working. But if I try to start the second container I get the following error:
docker run --name iroha1 -p 50052:50051 -v $(pwd)/node1:/opt/iroha_data -v blockstore1:/tmp/block_store --network=iroha-network -e KEY='node1' hyperledger/iroha:latest
key=node1
/opt/iroha_data
WARNING: IROHA_POSTGRES_HOST is not defined.
Do not wait for Postgres to become ready. Iroha may fail to start up
[2019-05-24 09:42:39.416652545][I][Init]: Irohad version: 1.0.0
[2019-05-24 09:42:39.417173322][I][Init]: config initialized
[2019-05-24 09:42:39.419332310][I][Irohad]: created
[2019-05-24 09:42:39.419510386][I][Irohad/Storage]: Start storage creation
[2019-05-24 09:42:39.419664393][I][Irohad/Storage]: block store created
[2019-05-24 09:42:39.425382813][E][Init]: Failed to initialize storage
If I use the postgres container of the first node for the second node no error occurs i.e. the iroha container starts.
Any help or suggestion is greatly appreciated.
The last line of the log that talks about storage failure to initialize is the cue.
To resolve this, make use of the second blockstore you created because the first blockstore blockstore1 is already in use. Make use of the second blockstore when starting the second iroha container e.g ... -v blockstore2:/tmp/block_store ...
Let me know if this is of help to you
Check your config.docker file and make sure you have the network set to iroha-network and make sure you have the ports right.
Related
I have started a new (.net core 3.0)project in Visual Studio, with Docker support (Windows)
I have added Docker support (right-click on project Add->Docker support) and in the same way added Docker compose support.
If I just Click "play-button" for Docker Compose, the project starts everything works well.
But when I run docker-compose up from the solution folder I get
Cannot start service testproj30: failed to create endpoint
testproj30_testproj30_1 on network nat: hnsCall failed in Win32: The
specified port already exists.
(I have closed my VS solution). If I remove the port mapping in docker-compose.override.yaml I dont get this error message. I have dont the most common tricks with restarting docker servce, hni service and so on. Nothing helps.
I dont want to depend on all VS-voodoo from the project file and God knows what other files that are involved.
I can run docker run -p 8080:80 443:443 without any port problems
I fixed a similar problem by removing some terminated container and then pruning networks.
List terminated container :
docker ps -a
Remove them (Cygwin syntax) :
docker rm $(docker ps -aq)
You will have error message for runnnig containers.
Clean your networks :
docker network prune
For myself, the main cause was the Docker killing process skiped the port releasing mechanism of my application.
I cant find more information about those.
Should we use docker stop for containers which we started with docker start
Or same for docker-compose up?
What is the difference between stop and down?
In docker-compose help
stop Stop services
down Stop and remove containers and networks (optionally images and volumes as well)
# Stop services only
docker-compose stop
# Stop and remove containers, networks..
docker-compose down
# Down and remove volumes
docker-compose down --volumes
# Down and remove images
docker-compose down --rmi <all|local>
Following are the differences among various docker-compose command options:
docker-compose up - start and restart all the services defined in docker-compose.yml
docker-compose down - command will stop running containers, but it also removes the stopped containers as well as any networks that were created. You can take down one step further and add the -v flag to remove all volumes too. This is great for doing a full blown reset on your environment by running docker-compose down -v.
docker-compose start - command will only restart containers stopped previously
docker-compose stop - command will stop running containers but won’t remove them
Just to answer the other part of the question:
Use docker-compose up to start or restart all the services defined in a docker-compose.yml.
The docker-compose start command is useful only to restart containers that were previously created, but were stopped. It never creates new containers.
The docker-compose run command is for running “one-off” or “adhoc” tasks.
For further information visit this page.
I tried to restart Postgres in Docker using 'docker restart ' command. It got stopped but I'm not able to start it. When I run the command 'ps -a' it says the status as 'Exited'. Is there any way to start it again? I don't want to loose any data in that database.
The container had one active connection during restarting. Is that creating a problem?
If the container crashed due to a bug or something, you may not be able to restart it. However, you should still be able to recover at least part of your data by making a new image out of the container that you want to recover. Here's how you do it:
First, list all the containers that have run in your machine:
docker ps -a
Find out which one is the container that run with all the data you want to recover. You should be able to figure out from the CREATED field (you know when you started it).
Grab the hash (CONTAINER_ID) of the container, and execute the following command:
docker commit <hash> <a_new_name:tag>
This will save the container as an image that you can execute.
Execute the container with a bash or sh session, depending on what our base image offers:
docker run --entrypoint sh/bash -it <a_new_name:tag>
This will give you access to the state of the container at the time of exiting, which will allow you to inspect its conditions, find bugs, and possibly recover some data. Good luck!
I'm new to docker. I'm still trying to wrap my head around all this.
I'm building a node application (REST api), using Postgresql to store my data.
I've spent a few days learning about docker, but I'm not sure whether I'm doing things the way I'm supposed to.
So here are my questions:
I'm using the official docker postgres 9.5 image as base to build my own (my Dockerfile only adds plpython on top of it, and installs a custom python module for use within plpython stored procedures). I created my container as suggedsted by the postgres image docs:
docker run --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword -d postgres
After I stop the container I cannot run it again using the above command, because the container already exists. So I start it using docker start instead of docker run. Is this the normal way to do things? I will generally use docker run the first time and docker start every other time?
Persistance: I created a database and populated it on the running container. I did this using pgadmin3 to connect. I can stop and start the container and the data is persisted, although I'm not sure why or how is this happening. I can see in the Dockerfile of the official postgres image that a volume is created (VOLUME /var/lib/postgresql/data), but I'm not sure that's the reason persistance is working. Could you please briefly explain (or point to an explanation) about how this all works?
Architecture: from what I read, it seems that the most appropriate architecture for this kind of app would be to run 3 separate containers. One for the database, one for persisting the database data, and one for the node app. Is this a good way to do it? How does using a data container improve things? AFAIK my current setup is working ok without one.
Is there anything else I should pay atention to?
Thanks
EDIT: adding to my confusion, I just ran a new container from the debian official image (no Dockerfile, just docker run -i -t -d --name debtest debian /bin/bash). With the container running in the background, I attached to it using docker attach debtest and the proceeded to apt-get install postgresql. Once installed I ran (still from within the container) psql and created a table in the default postgres database, and populated it with 1 record. Then I exited the shell and the container stopped automatically since the shell wasn't running anymore. I started the container againg using docker start debtest, then attached to it and finally run psql again. I found everything is persisted since the first run. Postgresql is installed, my table is there, and offcourse the record I inserted is there too. I'm really confused as to why do I need a VOLUME to persist data, since this quick test didn't use one and everything apears to work just fine. Am I missing something here?
Thanks again
1.
docker run --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword
-d postgres
After I stop the container I cannot run it again using the above
command, because the container already exists.
Correct. You named it (--name some-postgres) hence before starting a new one, the old one has to be deleted, e.g. docker rm -f some-postgres
So I start it using
docker start instead of docker run. Is this the normal way to do
things? I will generally use docker run the first time and docker
start every other time?
No, it is by no means normal for docker. Docker process containers are supposed normally to be ephemeral, that is easily thrown away and started anew.
Persistance: ... I can stop and start
the container and the data is persisted, although I'm not sure why or
how is this happening. ...
That's because you are reusing the same container. Remove the container and the data is gone.
Architecture: from what I read, it seems that the most appropriate
architecture for this kind of app would be to run 3 separate
containers. One for the database, one for persisting the database
data, and one for the node app. Is this a good way to do it? How does
using a data container improve things? AFAIK my current setup is
working ok without one.
Yes, this is the good way to go by having separate containers for separate concerns. This comes in handy in many cases, say when for example you need to upgrade the postgres base image without losing your data (that's in particular where the data container starts to play its role).
Is there anything else I should pay atention to?
When acquainted with the docker basics, you may take a look at Docker compose or similar tools that will help you to run multicontainer applications easier.
Short and simple:
What you get from the official postgres image is a ready-to-go postgres installation along with some gimmicks which can be configured through environment variables. With docker run you create a container. The container lifecycle commands are docker start/stop/restart/rm Yes, this is the Docker way of things.
Everything inside a volume is persisted. Every container can have an arbitrary number of volumes. Volumes are directories either defined inside the Dockerfile, the parent Dockerfile or via the command docker run ... -v /yourdirectoryA -v /yourdirectoryB .... Everything outside volumes is lost with docker rm. Everything including volumes is lost with docker rm -v
It's easier to show than to explain. See this readme with Docker commands on Github, read how I use the official PostgreSQL image for Jira and also add NGINX to the mix: Jira with Docker PostgreSQL. Also a data container is a cheap trick to being able to remove, rebuild and renew the container without having to move the persisted data.
Congratulations, you have managed to grasp the basics! Keep it on! Try docker-compose to better manage those nasty docker run ...-commands and being able to manage multi-containers and data-containers.
Note: You need a blocking thread in order to keep a container running! Either this command must be explicitly set inside the Dockerfile, see CMD, or given at the end of the docker run -d ... /usr/bin/myexamplecommand command. If your command is NON blocking, e.g. /bin/bash, then the container will always stop immediately after executing the command.
I have a docker environment with 5 containers that are composed via docker compose. Now only on mac machines and only sometimes (seems completely random) 1 of these 5 container doesn't start.
The weird thing about it is, that docker ps says the container is running and I can connect to it. Inside the container is a JBoss server and ps says that there is a process that runs the JBoss. BUT in fact the JBoss is not up and running. There is no logging in the docker compose console and JBoss not accessible.
There is also the problem that if this happens the whole docker-compose process cannot be canceled properly anymore. All containers shutdown and also can be forced to shutdown but the JBoss container. Then the docker-machine hangs up.
I didn't find any hint in the interwebs ... please help !
It seems that the process running inside the container is in a weird state.
Try killing it without providing a grace period, or removing the container.
stop : Stop a container by sending SIGTERM and then SIGKILL after a
grace period
--help=false Print usage
-t, --time=10 Seconds to wait for stop before killing it
kill : Kill a running container using SIGKILL or a specified signal
--help=false Print usage
-s, --signal="KILL" Signal to send to the container
rm : Remove one or more containers
-f, --force=false Force the removal of a running container (uses SIGKILL)
--help=false Print usage
-l, --link=false Remove the specified link
-v, --volumes=false Remove the volumes associated with the container
Moreover try checking the logs of the container:
docker logs --follow <container_name or container_id>
After updating to docker v1.10 the problem didn't occur anymore :)