Docker Community Forums

Share and learn in the Docker community.

How separate different environment to have different and separated applications

I bag pardon for stupid next questions but I’m not a programmer and use Docker as testing environment for different applications.
Now I got a Docker where I’ve installed postgres, pgadmin, erp application. Everything work fine.
My question is now about what to do to create another different parallel environment using i.e.
mariadb, phpmyadmin , another different erp application.

I mean that I would have two different desktop icons or two logins who link two different clean situation, not the sum of two with many many container to identify.
I’m worried to invent or try something because I have no the skills required.
Please use language for dummies…;-)) on reply

I am not quite sure what you currently have and what your goal ist.

Do you mean a single container or eg. a docker-compose setup?

What login links? Docker is usually just console stuff. There is no need to login into something using an icon?

Do you want to do this to test your stuff with a different environment?

If you want to test your stuff with different environments using docker I suggest you take a look at docker compose

You can then create multiple compose files, which describe the same architecture, which you can then use to test. For example compose-1 could specify a postgres DB and pgadmin, compose-2 could create a mysql DB and a phpmyadmin container.

Hello and thanks for reply

this is what I have now as to test Idempiere ERP . I run the applications one at time and then Idempiere

What I’m wondering is … if I add other 3 or four application for ERPNext it start to be confusing to run every time the right applications.
So my question is about if it possible to have something similar of above environment separated for ERPNext testing

If I run these command below after pulling for me it becomes a bit messy

run data container
docker create -v /home/frappe/frappe-bench/sites/site1.local/ -v /var/lib/mysql --name erpdata davidgu/erpnext

run erpnext
docker run -d -p 8085:8085 --name erpnext --volumes-from erpdata davidgu/erpnext

get passwords
docker exec -ti erpnext cat /root/frappe_passwords.txt Login on http://localhost with Administrator / password

Probably it’s not so clear because I’m trying to use docker only because I got my pc full of many application and servers like Wampserver, Apache Tomcat…more than one… and and so it’s a way to take away
these testing environments from the other stuff

Docker compose in short words is about to concentrate in only one container many of them ?
Compose_Idempiere ( 1)Postgres 2)PgAdmin 3)Idempiere) Run all once ?

Quick tip: docker run -v /home/frappe/frappe-bench/sites/site1.local/ -v /var/lib/mysql --name erpdata davidgu/erpnext does the same thing and saves a line.

I think docker-compose is what you want for your setup. Docker compose makes it possible to start multiple containers (not combine everything into one container), and configure them in one file. This way all you need to do is type docker-compose up or docker-compose down to start or stop the whole setup.
No need to create the single containers manually.

Docker-compose is closely related to docker and if you are using docker desktop on windows already installed. No need to download any additional software.

If QA is using a dev environment, that environment is likely changing. It is hard to control the state of the environment with multiple people working against it.
Typically, QA environments mimic more closely production environments than do development environments. This helps ensure functionality is valid in an environment that is more production-like.
Developers tend to have lots of tools and things running in their environment that could affect QA validation.
You usually setup a separate QA environment, because you want to give the testers an isolated environment on which to test, so that developers and testers can work at the same time.
This allows reporting on a common revision so developers know whether particular issues found by testers has already been corrected in the development code.
Face the distinct possibility of releasing critical defects to customers because it’s not testing in a real-world environment.
The test team won’t see the issues when the environment is not the same because the playing field, so to speak, is not even.
Testing on a qa environment provides a more accurate measure of performance capacity and functional correctness
As Web applications become more mission-critical for customers, it becomes increasingly important to test on environments that exactly mimic production because it’s production where customers use your application