![\"laravel](\"https:\/\/www.directimpactsolutions.com\/wp-content\/uploads\/2024\/07\/Laravel-deployments-758x1024.png\" "\\"Laravel-deployments\\"")
<\/figure><\/div><\/p>
Docker Containers vs. Virtual Machines<\/h2>
In older, more traditional virtual machines (VMs), configuration would look like that of a bare-bones server, with a fully featured operating system and all the necessary software for the tech stack installed on top of that.<\/p>
Docker containers are typically more lightweight. Each Docker container uses the kernel<\/a> of the host\u2019s operating system instead of having its own. Furthermore, each container is typically broken down into the smallest possible component.<\/p> Despite the fact that Docker containers make use of the host machine\u2019s kernel, they have no knowledge of the host machine, and thus operate in isolation. This can be a huge benefit for security.<\/p> Knowing that Docker containers are typically broken down into small, bite-sized pieces, it follows that with larger or complicated applications, we might need multiple. In those cases, will need to be able to orchestrate them together harmoniously; that\u2019s where Docker Compose comes in. Docker Compose offers a clever configuration file structure that the engineer can use to define all the parts and how they will work together.<\/p> For example, I could define a Docker Compose configuration file that would specify that both a database server and a web server are needed, and that the web server depends upon the database server being available.<\/p> Once configuration for Docker Compose has been defined, setting up your environment is typically just a single command away. Teardown is just as simple.<\/p> We\u2019ve been using Docker technology to standardize our development environment for some time now; this has made a tremendous difference in several ways.<\/p> Each of our developers’ own local environments are now exactly the same, which eliminates the \u201cIt works on my machine\u201d problem. This is true even with developers using all the main Operating Systems (Windows\/Mac\/Linux)<\/em>. Developer machine deployments are now swift and efficient, as they\u2019re all standardized, and deployed in a standardized fashion, typically with a single command.<\/p> Another great thing about working with Docker containers is that all the software needed for a project is typically contained within the containers, making it very easy to switch between projects without worrying about conflicting software configurations. Also, Docker Compose is self-documenting in a way; by keeping its configuration within our repositories, it\u2019s quite simple for us to determine which version of PHP a system was designed around (as an example).<\/p> Here at Direct Impact Solutions, we\u2019ve used the Laravel PHP Framework<\/a> for a significant number of systems. The good folks who created the Laravel framework have even adopted usage of Docker as their default installation method using their own Docker Compose system, Laravel Sail<\/a>. Laravel Sail is customizable and easy to use, so we\u2019ve made use of it within some of our projects. I like how easy it is to add new service containers into a project. For instance, once you get to a spot in your development where your application needs to send emails, you can quickly add a container for One unfortunate thing about Laravel Sail, however, is the fact that it does not make use of a traditional web server, but rather an artisan command ( Since Laravel Sail is built using Docker compose technology, it should (in theory) be possible to make it work using a traditional web server so that we would not have the limitations that prevent us from using this tech in production. Unfortunately, I suspect that this won\u2019t be happening any time soon. This may have something to do with the fact that the developers of Laravel and Laravel Sail also have a production deployment and management product known as Laravel Forge<\/a>.<\/p> Due to our appreciation for standardization, simplicity, and Docker\/Sail, we are looking into other technologies in hopes of finding something that offers the continuity we want between dev and production environments.<\/p> ServerSideUP has recently published an open-source development tool, Spin<\/a>, that\u2019s very similar to Laravel Sail. Spin aims to do exactly what we originally wanted from Laravel Sail, and then some! Not only does it allow us to reuse the same dev environment within production, but also it does more.<\/p> In order to begin using Laravel Sail, the engineer would often run Spin checks for updates when you run the In theory, using Spin for both dev and production deployments should always yield identical environments for end users. Separate A project that has Spin integrated will come with other configuration files beyond the simple Docker Compose configuration files. These additional configuration files let the engineer define details about SSH connections and the user accounts that will be responsible for deploying the solution. When being deployed to a production environment, Docker Swarm technology is used. There\u2019s even a Since Spin utilizes a number of configuration files that could potentially hold sensitive information, it\u2019s important to note that Spin highly encourages encryption of these files. Once encrypted, you can confidently commit and store these files within your repository. Spin comes equipped with its own vault<\/a> which contains commands for encrypting, decrypting, editing, etc.<\/p>What is Docker Compose?<\/h3>
Benefits<\/h3>
Laravel + Docker = Sail<\/h2>
mailpit<\/code> using baked-in commands.<\/p>Laravel Sail Wishlist<\/h3>
artisan serve<\/code>) that acts as a wrapper around PHP\u2019s built-in web server<\/a>. This is unfortunate because PHP\u2019s built-in web server runs only one single-threaded process. As such, it\u2019s not designed to handle multiple requests and should not be used for production environments.<\/p>Where To From Here?<\/h3>
Spin<\/h2>
Spin Usage<\/h3>
sail up -d<\/code> from the command line.
Similarly, when using Spin instead of Sail, one can execute spin up -d<\/code> to create an environment. Similar commands are provided for running commands inside of the Docker containers as well (it\u2019s common to run PHP artisan<\/code> commands from the PHP<\/code> container, and npm run<\/code> commands from the node<\/code> container).<\/p>Spin Update Checks<\/h3>
spin up<\/code> command. That\u2019s refreshing to see, and not something I\u2019ve seen in Laravel Sail.<\/p>Spin Environment Discrepancies<\/h3>
Docker-compose.yml<\/code> files are provided for both, however, so for those instances where some things need to change between environments (example mailpit<\/code> in dev, proper mail server in production), Spin has you covered. There are Docker-compose.yml<\/code> files provided for dev, production, and even continuous integration (CI).<\/p>Spin Configuration<\/h3>
.spin-inventory.ini<\/code> file in Ansible inventory format<\/a> where you can define the servers to be used.<\/p>Spin Encryption<\/h3>
Zero-Downtime Deployments<\/h3>