[LightDestory]

I'll do a couple of posts in this thread. The first would be a quick review of the OP highlighting the main issues I had reading it. The second will address @deanhills' questions and @LightDestory's answers to them. May be later on, I'll open a more comprehensive thread on Linux containers and where Docker containers rank among them.

Here I won't go back to my previous principled objection (done elsewhere on this board) of using Docker inside a KVM VPS and just go along the assumption that the resources are good enough to get everything run smoothly.

Okay, now, for the OP's review. I understand that it wasn't planned to be a stand-alone topic from its intro. but still the whole OP fails on so many points that I can't just let it pass un-annotated--at least not under my watch :-)

1- The Why Docker Container Part:

From the above we deduce that the main incentive in using Docker containers here is the isolated, ephemeral and statelessness of the Docker container that makes it disposable, i.e. just throw the container away and spin up another one.

Nothing wrong there, in fact, it's perfectly what Docker containers are designed for:
> Docker containers are "ephemeral, stateless, minimal containers that won’t typically get upgraded or re-configured but instead just be replaced entirely.”

Although I did sense a bit of confusion in this part of the last paragraph.

It might be due to a lack of a clear view of what a container is really all about?!.. A container can be mentally viewed as a process tree running inside its own namespace (hence the isolated environment); the malware resides(/confined) somewhere in that process tree. Once the container is destroyed, ie the process tree killed, the malware is killed too from within.. That simple!

2- The Docker Container Creation Part:

Unfortunately this part is all wrong!.. And I don't recommend using it at all!.. Nothing in it makes sense as far as Docker container best practices go.

The example above download a Docker Debian-latest image and runs it on the fly in interactive mode to gain access to the shell from which it ask you to follow @Mashiro's tutorial!!..

Well, GoodBye the minimal container part that the Docker container definition is based on.

Even more, goodbye the ephemeral and stateless argument that the whole OP is based on (re-read section 1 about the CVE stuff and spinning up containers at will.) If each time we want to recreate our container after a malware infection we have to go through the whole @Mashiro's tutorial again!!!.. I would say that we didn't gain anything in this process, we just added the extra Docker part to the @Mashiro's already lenghty tutorial!..

Remember, we've said that:
> Docker containers are "ephemeral, stateless, minimal containers that won’t typically get upgraded or re-configured but instead just be replaced entirely.”

So, what's the solution?.. If we really want to do what the OP suggested, then we need to use a system container (like LX D/LXC containers) not an application container like Docker containers.

But if we still want to stick with Docker, then we need to create 2 Docker images: one for a database, ie MySQL/MariaDB, and one for the Nginx/PHP+WP  or Apache/PHP+WP.

Both type of images are already available online but I will advice people to create their own Docker images by familiarizing themselves with Dockerfiles (pretty easy to pick up on.)

That should be all till Post_2.

Thanks for your time replying this post, but please read Mashiro's post too to understand the nature of this topic.

As you said it was a un-scheduled tutorial, I didn't prepare any good material for it. 

I know, and already said on the OP, that this configuration was not optimal.

On this tutorial I said that the container was not optimal because we were abusing of it. Installing every component of application-stack such as WP on the same container is not a good practice... but create different containers and make them communicate is not a 0-knowledge thing.

When I mentioned Docker on Mashiro post, I have been replied that using Docker was a no-learning process because it was a nice excercise to set up from scratch the entire STACK applications. So.. I edited this tutorial for that in my mind: allowing the user to perform that guide inside a container.

It is not a good practice to abuse of the container like that but if you destroy the container you delete the volatile-volume linked to that containers and so you will delete both your data and the miner binary. I wanted to set up a "data" volume but it was out-of-level of a new user. Moreover, I didn't suggest the mount fs to volume option because it is dangerous if the miner binary or scripts get on your vps.

Do you except a someone new to Docker, as @deanhills, to master the concepts of persistents volumes, internal networking and container composition with docker-compose on a simple forum's post? There skills need time to master and a lot of try-and-error to get the confidance to get them work without any issue. Copy-paste a configuration from github will make it works but you will have 0 knowledge on how it is working. If you somedays want to build something different, such as a data pipeline where a LOT of software need to communicate, you will need the knowledge!

If I wanted to do a complete tutorial of WP+Mysql on Docker I would not do much on writing it. Because github is FULL of composition for this stack, moreover Mashiro has already wrote about portainerio and it has a stack template for WP. I would suggest use Portainer and learn how it configures that stack, it creates a internal networks and has good healtycheck for the containers.