Docker is just going to be used to run the applications which host your website. What you need to decide first is what your website will be and that will inform the decision on what technologies will be used to host your website. For example, if you are thinking of something like a blog, you might choose WordPress as the main hosting platform. This will need some sort of database behind it, for which you might choose MySQL or Postgres. You would also need some sort of web server software, which you might choose Nginx or Apache. At a basic level, you could now have the entire web stack defined: E.g. WordPress, MySQL, Nginx.
Ok, so now you need to sort out where those technologies will run. The easy, older solution is to spin up a physical box and load all of the software packages on the native Operating System (OS) of that box. This works perfectly well, until it’s time to start patching and updating the OS and software. And you will want to do those updates. This will probably go well for the first few upgrades, but eventually something will go sideways. Often this will be that several of your software packages will require different version of the same, underlying library. Or, something will just not install right and your website stops working. This is where docker comes in.
Docker lets you run each software package in it’s own contained environment. Each application runs in it’s own container, and the other containers are only reached via network calls. It’s like having a separate virtual machine for each service (this is how we used to actually run stuff like this); but, without all the overhead of actually having multiple virtual machines. So, even if you upgrade package XYZ in the Nginx container to version 2.1, the MySQL container could have package XYZ still running at version 1.9. Neither container knows or cares about what is running in the other containers.
The other advantage of containers is that the base OS and software in the container is usually well defined and doesn’t change much. The container will be able to reach permanent storage for any configuration and data files. But, if something goes wrong with the OS or software inside the container, then that container is destroyed and a new copy spun up and attached to the config/data storage. Software upgrades can also take advantage of this, as you can often stop the current container and start a container running the new version of the software, attach it to the config/data storage and maybe run some sort of “upgrade database” command. This makes for less mistakes and chances for things to not go well.
If your goal is to learn to self host, I would recommend putting those posts over in the !selfhosting@slrpnk.net. They are likely to get a better reception than in the programming and Linux communities you spammed with this post. Though, even there you may run into a bit of the RTFM! vibe you got here if you are posting questions without context and which appear to be low effort “I want to do something but have made no attempt to learn anything on my own”. I’d recommend spending some time reading long form blogs/guides on web hosting and watching YouTube videos. Again, long form stuff. Skip the clik-bait-y crap with titles like “get your website running in 5 minutes! <insert stupid emojis here>”. You’ll want to learn the basics on Docker and what is required to run and host a web site. Once you are able to get containers going, try setting up a web stack on your local system (don’t go paying for anything yet) and see if you can get it working and understand how it works. You’re almost certainly going to screw it up a few times in the process, that’s ok. That’s another great feature of containers, you can bork them up really, really bad and not have to care. You delete the container, maybe wipe the attached storage and try again.
Docker is just going to be used to run the applications which host your website. What you need to decide first is what your website will be and that will inform the decision on what technologies will be used to host your website. For example, if you are thinking of something like a blog, you might choose WordPress as the main hosting platform. This will need some sort of database behind it, for which you might choose MySQL or Postgres. You would also need some sort of web server software, which you might choose Nginx or Apache. At a basic level, you could now have the entire web stack defined: E.g. WordPress, MySQL, Nginx.
Ok, so now you need to sort out where those technologies will run. The easy, older solution is to spin up a physical box and load all of the software packages on the native Operating System (OS) of that box. This works perfectly well, until it’s time to start patching and updating the OS and software. And you will want to do those updates. This will probably go well for the first few upgrades, but eventually something will go sideways. Often this will be that several of your software packages will require different version of the same, underlying library. Or, something will just not install right and your website stops working. This is where docker comes in.
Docker lets you run each software package in it’s own contained environment. Each application runs in it’s own container, and the other containers are only reached via network calls. It’s like having a separate virtual machine for each service (this is how we used to actually run stuff like this); but, without all the overhead of actually having multiple virtual machines. So, even if you upgrade package XYZ in the Nginx container to version 2.1, the MySQL container could have package XYZ still running at version 1.9. Neither container knows or cares about what is running in the other containers.
The other advantage of containers is that the base OS and software in the container is usually well defined and doesn’t change much. The container will be able to reach permanent storage for any configuration and data files. But, if something goes wrong with the OS or software inside the container, then that container is destroyed and a new copy spun up and attached to the config/data storage. Software upgrades can also take advantage of this, as you can often stop the current container and start a container running the new version of the software, attach it to the config/data storage and maybe run some sort of “upgrade database” command. This makes for less mistakes and chances for things to not go well.
If your goal is to learn to self host, I would recommend putting those posts over in the !selfhosting@slrpnk.net. They are likely to get a better reception than in the programming and Linux communities you spammed with this post. Though, even there you may run into a bit of the RTFM! vibe you got here if you are posting questions without context and which appear to be low effort “I want to do something but have made no attempt to learn anything on my own”. I’d recommend spending some time reading long form blogs/guides on web hosting and watching YouTube videos. Again, long form stuff. Skip the clik-bait-y crap with titles like “get your website running in 5 minutes! <insert stupid emojis here>”. You’ll want to learn the basics on Docker and what is required to run and host a web site. Once you are able to get containers going, try setting up a web stack on your local system (don’t go paying for anything yet) and see if you can get it working and understand how it works. You’re almost certainly going to screw it up a few times in the process, that’s ok. That’s another great feature of containers, you can bork them up really, really bad and not have to care. You delete the container, maybe wipe the attached storage and try again.
Good luck.