Docker ‘Run’ Won’t Work if Command is Appended
We use Docker ‘run’ for much of our testing environment here. Starting a Docker Container with certain features, such as where the Container automatically starts the database, won’t work if a command is appended to the end of the Docker ‘run’ command.
For instance, images from the Postgres Docker site https://hub.docker.com/_/postgres/ will automatically start the database whenever the Container is started. The command:
sudo docker run -it postgres:9.3 /bin/bash
will start the Container with the image named ‘postgres:9.3’ and put the user into a bash shell which will interact with the Container, but the database will not start. Only the bash shell will run, and this prevents any automatic startup of the database. The solution is to start the Container without any commands on the end:
sudo docker run -it postgres:9.3 # Starts the Container using the postgres:9.3 image. The database is automatically started.
then start another PuTTY (or whatever command line tool you prefer) window, and enter the already running Container via a shell:
sudo docker ps # get the id of the Container
sudo docker exec -it /bin/bash # enter the running container through the bash shell
Now you’re in the container via a bash shell, so you can use psql to manipulate the database
su – postgres # only the postgres user can run psql. Other databases may differ.
psql # this puts you into the psql client, and the command prompt will look like
Now you can manipulate the database via SQL and DDL commands.
Docker has been around for several years now, and there have been well over 100 million downloads of the software. The amount of activity involved is impressive. Blogs, technical websites, etc. are buzzing with activity concerning this product, because the ideas are revolutionary: more bang for the buck as far as spin-up time in a Container vs a VM, the number of Containers that can fit in a metal box vs the number of VMs in the same box, and the ability to put each discreet part of an application into its own Container, to name a few. It’s still not ready for prime time in Production IMHO, but the potential is astounding. We may very well see an explosion of competing products in the coming years, as well as products that enhance or improve Docker and other Container based products.
- A Microservice Service Catalog for Incident Response
- Domain Driven Design Catalog to Tame Microservice Sprawl
- Microservice Architecture and Your Logical Application
- Microservice Configuration Management
- Continuous Deployment and DevOps at Scale
- Register for DeployHub Team
- Reverse Proxy Setup for SaaS Deployments
- DeployHub Team User Guide
- The Hipster Store Tutorial
Ortelius Open Source Project
All Blogs on Kubernetes Microservices
- How to Navigate the Deathstar
- Microservice Continuous Integration – Where’s the Build?
- Working with Helm for your Microservices Releases
- On Versioning your Container Content
- How to Use a Domain Driven Design
- Versioning Applications
- Why we need Application Packages for CD
- Version Jumps and Tracking
- How are Microservices and Applications Related?
- Migrate to Microservices with a Domain Driven Design