create docker-compose.yaml #387
Conversation
Starts pico in a docker container with the files mounted. docker-compose up
|
First of all: Thank you for your contribution @Foolre! 👍 I was thinking about this and there are some problems from my perspective. I'm unfortunately not very experienced with Docker, so please pardon possible misunderstandings if I'm wrong. The only direct issue with your PR is that it uses PHP's built-in webserver, which is intended for testing and development purposes only. PHP's docs expressly state that it "should not be used on a public network" (i.e. in productive environments). Thus a official Docker container for Pico should rather use a Apache- or FPM-based container. This leads us to a more general problem: Decisions. Should Pico's official Docker container rather use Apache (i.e. As you can see there are a bunch of variables I'm not sure about to make a definite decision. Creating a Docker container for Pico is no big deal, it doesn't really differ from the normal installation instructions, just instead of directly executing the commands we put them in a config file. Users might want to make their own decisions regarding the Docker image to use (see above). Thus I tend to rather create a appropriate section on our website describing (ref: @smcdougall) how using Pico with Docker might look like. However, I definitely didn't make a decision yet, feedback and other opinions (including yours @Foolre!) are highly appreciated! |
|
@PhrozenByte Totally not running Pico in a richarvey/nginx-php-fpm container for all my sites at the moment. 😒 I'm not super experienced with Docker. I've done their tutorials around the basics of pulling and running containers, but checked out around the time Docker Compose and multi-container orchestration started becoming the focus. It's an area I'd love to learn more about, but it's hard to wrap your head around the subject matter when it scales up so quickly. (My brain unfortunately doesn't run Docker, so it can't just scale up to match the needs of reading their documentation. 😆) From what I know though, all the concerns you've laid out are valid ones. There are a LOT of decisions to be made around this. Shipping Apache for instance, would be be very in line with our "Stupidly Simple" mentality... but not so much on the blazing fast, low resource / overhead part. Although running in Docker would seem to mitigate some of the risk of using PHP's built in webserver, I've read plenty to suggest that escaping the confines of a Docker container is far from impossible. Sadly, that means that any official Pico Docker container would need to be treated and secured just as well as a regular installation would. There's a lot to discus about this, but I think it could be an interesting topic for the future. 😃 |
|
The file I commited is made for local dev/testing of Pico. It mounts the code as a directory, it doesn't contain a copy of the source code. From a Pico-in-production-under-heavy-load perspective, FPM would probably be the best choice. This enables scaling both the webserver and FPM instances seperately. For simplicity I would stick to mod_php. When it comes to considering the webserver or php version, I suggest to go for the best documented / supported options. Regarding the container base, my personal preference on this is Debian-slim. However alpine is (a bit) smaller, by keeping Docker images small they can be transferred back and forth much faster. Alpine can be useful when you want to squeeze every bit of performance out of your box. But you have to deal with the musl compiler, documentation. Building and maintaining Alpine-based Docker images is something I find annoying and they're actually not safer as often projected. Just a bit smaller and a bit more efficient. Further on, I think a Docker container should contain one service, expose 1 port and the image should be ephemeral. So going for the full feature images including text editors, sshd etc. isn't something I would consider. In the end these are considerations an operator should decide for himself on a case by case basis, possibly together with a developer. Once the needs of the user get more complex (seperate scaling of the PHP instance for example) it is fair to expect the user is able to do this himself. However Docker can make it simple to try out, test and develop apps quickly, which was the idea behind my pull request. But I changed my mind about putting it in the source code, maybe it's a better fit in the documentation with some examples. |
|
Overall, the hardest part of this is that, if/when we provide an official Docker container, it has to be set up exactly how we want to deliver Pico to our users. It's not just that we have to make a lot of decisions about the software, it's that we have to choose what we feel would be best for the user. We don't really have the time or resources to maintain multiple branches ("tags", I guess, in Docker), so we really have to nail one or two (at most) as being the Pico setup. And really, the only reason I say "or two" is because I think the possibility to choose between an Apache or FPM based container would provide a lot of benefit to users. @PhrozenByte would probably agree with you about the Debian base (:wink:), but an Alpine container wouldn't be hard either, since it could likely be based on the existing Apache and FPM containers. Normally it would be more difficult to target Alpine due to possibly having to compile code or package specifically for it, but that's not an issue with Pico. The composer commands would be the same. Debian though, would provide the user with more utility if they wished to modify or base their own container on top of ours.
That is the Docker project's core philosophy, as far as I know. 😉 Another consideration we haven't touched on is how the actual usage of the Docker container would work. Where does the user mount their files? How do we split that up? Pico's root directory contains three to five folders that any given user will need access to ( On a side note, that's how I split my own Pico sites up. Each site has a unique So how do we handle these folders? Do we configure five separate mountable volumes? That seems like it would be a bit messy. Also, any existing content (the sample config, optional plugins, the default theme, and the sample content/inline docs) would be mounted over. It's hard to come up with a one-size-fits-all solution for these issues.
True, but that's also part of the usefulness of Docker. If we do provide a decent base container, it could be customized by any user to fit their own needs. So I definitely think it's something we should do in the future.
This is something that could maybe be done in the short term, however I personally don't feel up to it at the moment. I think that most likely, a good time to target all this for would be the upcoming release of Ultimately though, the same decisions would have to be made before hand, be they suggestions in the Documentation, or decisions we make in composing our own container. Any documentation we provide has to reflect what we feel is best for our users. |
Even though our decision was to create a Docker tutorial just in the short-term and to create a actual Docker container in the long-term, I guess that it's rather realistic that we just create a Docker tutorial in the long-term 😉 I've added this to our website's ToDo list (see picocms/picocms.github.io#7). Please note that postponed is not abandoned, but since it's rather a long-term thing I'm closing this now. We will get back to this PR when creating the Docker tutorial... 😄 |
Starts pico in a docker container with the files mounted. docker-compose up