mirror of
https://github.com/cytopia/devilbox.git
synced 2024-12-24 23:16:41 +00:00
77 lines
3.1 KiB
ReStructuredText
77 lines
3.1 KiB
ReStructuredText
|
****************
|
||
|
|
Devilbox purpose
|
||
|
|
****************
|
||
|
|
|
||
|
|
The Devilbox aims to provide you a universal zero-configuration LAMP and MEAN development
|
||
|
|
environment for any purpose which is setup in less than 5 minutes.
|
||
|
|
|
||
|
|
Its main intention is to support an unlimited number of projects for any framework or cms
|
||
|
|
and be portable accross all major operating systems, as well as providing any available php version
|
||
|
|
with whatever module you require.
|
||
|
|
|
||
|
|
To be portable, customizable and as leight weight as possible, the choice fell on a Dockerized
|
||
|
|
setup.
|
||
|
|
|
||
|
|
|
||
|
|
Why did I built this?
|
||
|
|
=====================
|
||
|
|
|
||
|
|
In one of my previous jobs I had to maintain around 30 different PHP projects. Many of them
|
||
|
|
utilized different versions and configuration, thus I had to switch between my local MacOS and
|
||
|
|
various Linux VMs on a frequent base in order to fullfill the current requirement.
|
||
|
|
|
||
|
|
Setting up new vhosts, local DNS entries, self-signed https certificates, installing other PHP
|
||
|
|
versions, ensuring I had all modules and lots of other initial configuration was always a pain to
|
||
|
|
me, so I decided to automate this.
|
||
|
|
|
||
|
|
|
||
|
|
Automation is key
|
||
|
|
=================
|
||
|
|
|
||
|
|
A few month after releasing it on Github I hit another problem: Tickets regarding outdated versions
|
||
|
|
as well as new major version requests accumulated and I spent a lot of time keeping up with
|
||
|
|
updating and creating Docker images and making them available.
|
||
|
|
|
||
|
|
That was the point when I decided to create a fully automated and generalized build infrastructure
|
||
|
|
for all custom Docker images.
|
||
|
|
|
||
|
|
The outcome was this:
|
||
|
|
|
||
|
|
* Docker images are generated and verified with Ansible
|
||
|
|
* Docker images have extensive CI tests
|
||
|
|
* Docker images are automatically built, tested and updated every night and pushed on success
|
||
|
|
|
||
|
|
|
||
|
|
Issues with Docker encountered
|
||
|
|
==============================
|
||
|
|
|
||
|
|
One of the major issues I have encountered with Docker is the syncronization of file and
|
||
|
|
directory permissions between local and Docker mounted directories.
|
||
|
|
|
||
|
|
This is due to the fact that the process of PHP or the web server usually run with a different
|
||
|
|
``uid`` and ``gid`` as the local user starting the Docker container. Whenever a new file is created
|
||
|
|
from inside the container, it will happen with the ``uid`` of the process running inside the
|
||
|
|
container, thus making it incompatible with your local user.
|
||
|
|
|
||
|
|
This problem has been finally addressed with the Devilbox and you can read up on it in much more
|
||
|
|
detail here: :ref:`syncronize_container_permissions`.
|
||
|
|
|
||
|
|
|
||
|
|
Today's state
|
||
|
|
=============
|
||
|
|
|
||
|
|
Honestly speaking, in the time I spent to build the Devilbox, I could have configured every
|
||
|
|
possible VM by now, but I would have missed the fun. I learned a lot and in the end it made my
|
||
|
|
work much more pleasent.
|
||
|
|
|
||
|
|
|
||
|
|
Tomorrow's state
|
||
|
|
================
|
||
|
|
|
||
|
|
I use the Devilbox on a daily base and together with other developers we find more and more edge
|
||
|
|
cases that are being resolved. As technology also advanced quickly, the Devilbox needs to keep up
|
||
|
|
with as well. Next major milestones will be to modularize it for easier customization of currently
|
||
|
|
not available Container, hardening for production usage and workflows for deployments in a CI/CD
|
||
|
|
landscape.
|
||
|
|
|