Titouan Galopin has written up a post to his Medium.com site showing a method he's created to set up a scalable Symfony application on Kubernetes, a container management system.

Modern web applications are complex. The expectations of your users regarding your application are constantly increasing: nowadays, an application needs to be fast, convenient, easy to use and beautiful.

Meeting these demands can become another difficulty in the path towards creating a great product. [...] To ease this new difficulty and decrease the time spent on creating and maintaining these expected features, a modern application usually leverages many different components, from content delivery networks (CDN) to full text search services and load balancers.

[...] When you use such infrastructure, being able to interact easily with all its components from within your application is critical. This is where Kubernetes and Symfony are working together to help you achieve incredible results, extremely quickly.

The post starts by introducing some of the basics around Kubernetes for those not familiar with it and the platform they'll be using: Google Cloud Platform. He then talks some about using Symfony in a Kubernetes environment and the role that scalability plays in how you write your code. He makes a few suggestions to make it easier including:

• Use Flysystem to store your application files in the managed file store
• Configure Doctrine to use the provided SQL service
• Use Redis for your cache and your sessions

There's a description for each item in the list, configuration examples where they'd help illustrate, and some links out to other resources for more information.

Matt Sparks has posted the next tutorial in his "Building a PHP framework" series to his site today. In this latest article (part seven in the series) he focuses on building the container to handle dependencies.

Part 6 began our discussion of PHP containers. Today, I’ll be going into greater detail of the subject and, along with that, I’ll run down the work done so far on the Analyze container.

A huge debt of gratitude goes how to the folks behind the PHP League Container and others. I’ve learned a ton studying their code.

He then walks through the use of the container he created, Analyze/Container, to create and extract a Carbon instance. He then covers how the container is working behind the scenes to initialize the instance complete with dependencies (and optional arguments).

Continuing the theme of posts related to using PHP on the OpenWhisk serverless platform, Rob Allen has posted a few notes for working with the PHP runtime.

These are some notes for working on the OpenWhisk PHP Runtime, but are probably applicable to the other runtimes too.

His notes cover:

• some basic setup
• building the two containers (PHP 7.1 and 7.2)
• running tests
• using the container interactively
• checking the format of Scala files

Commands are included for each item along with some of the output to expect.

In a new post to his site Matthias Noback walks you down a road to dependency injection, sharing his process of migrating a codebase from static calls to a more modern, robust dependency injection pattern.

I've worked with several code bases that were littered with calls to Zend_Registry::get(), sfContext::getInstance(), etc. to fetch a dependency when needed. I'm a little afraid to mention façades here, but they also belong in this list. The point of this article is not to bash a certain framework (they are all lovely), but to show how to get rid of these "centralized dependency managers" when you need to.

He talks about this common use case of "statics everywhere" and some of the problems with coupling your code to a static way of doing things. He walks through the steps towards modernization including injecting the container itself into the controller and shifting logic out into services. He also makes suggestions on what to do when constructor injection isn't possible and how to deal with "temporal coupling".

In a new post to his site, Tomas Votruba has a post sharing his thoughts about why you should combine Symfony Console and dependency injection and how it can help tp resolve issues with the overuse of static methods and functions.

I saw 2 links to SymfonyConsole in today's Week of Symfony (what a time reference, huh?). There are plenty of such posts out there, even in Pehapkari community blog: Best Practice for Symfony Console in Nette or Symfony Console from the Scratch. But nobody seems to write about the greatest bottleneck of Console applications - static cancer. Why is that?

He starts with some examples of the current status in PHP console applications including PHP_CodeSniffer, PHP CS Fixer and PHPStan. Each of these load commands to add functionality to the application which, as the application grows and changes, could be difficult to maintain in the future. Instead he recommends making use of dependency injection. He then talks about how containers are already a part of the console applications mentioned and finishes up focusing on the combination of the SymfonyConsole and SymfonyDependencyInjection components.

The Learnk8x.io blog has a tutorial they've posted showing you how to deploy a Laravel application to Kubernetes. Kubernetes is a system created to make it simpler to deploy containerized applications in a clustered context.

Vagrant is very good with setting up a local environment similar to a remote server. However, in production, you will most likely require more than just one web host and one database. You’ll probably have separate services for several requirements. You also need to have mechanisms in place to ensure that the application is always online and that the servers can efficiently balance the load.

In this article, I’ll explain how to deal with the simple requirement of running a Laravel application as a local Kubernetes set up.

The article then gets into the "whats" and "whys" of using Kubernetes and an introduction to the Minikube local Kubernetes environment. It runs through some of the prerequisites to getting the deployment set up and provides the Docker configuration to create and link the containers together. With that defined it provides the commands to get the environment up and running and the application deployed. The final part of the tutorial covers the scaling of the system and allowing ingress to the application through a certain URL.

On his site Robert Basic covers a useful site for the PHP developers out there using (or wanting to use) Docker for their development. In this post he talks about the PHPDocker.io service that allows for the easy creation of a Dockerfile customized to the needs of your own environment.

Recently I’ve been also learning a bit more about PHPDocker.io.

He includes an example of the Docker configuration that's output from the service for a simple webserver+MySQL+PHP-FPM setup. He also includes a small update to allow the MySQL server to store its data on the local system rather than inside the container (where it would be lost on each build).

In a previous post to his site Andrew Embler provided a "concrete guide to dependency injection", a method to help make code easier to test and more flexible/maintainable. In this latest post he continues the series and moves to the next topic: dependency injection containers.

I recently posted about dependency injection, a guide that I hope was easy to read and understand. It's a topic that's confusing, due in no small part to its name. As I mention there, the same term defines the simple process of externally providing instance variables to a class as it does to the Container object's magical auto-instantiation of object (which also "injects dependencies.")

I'd like to talk a bit more about that. Now that we understand the term "Dependency Injection" (which is simply providing classes to classes through a constructor or a setter), let's talk about how we might make this a little less onerous.

He starts with an example from the concrete5 project where a class would require three object instances each time it would be created. Fortunately the software includes a make command that does some of this work for you. It makes use of a dependency injection container behind the scenes to get the instances it needs. He then covers cascading dependencies, some special logic for class creation and how to "get fancy with it" by defining custom logic when an instance is created.

On the Hackernoon site Youssouf El Azizi has posted a quick tutorial showing you how to use Vessel with Docker and Laravel to create a "zero config" setup quickly and easily.

This article is a step-by-step to get started with Vessel ( the new way to setup the Laravel setup config with docker).

[...] Vessel is a lightweight docker environment for Laravel, that means it is just a small set of files that set up a local docker development environment per project and there is no extra thing to install globally, expect Docker system itself.

The tutorial then walks you through the process you'll need to follow to get the environment up and running including the installation of Docker/Docker-compose. It then walks through the installation of Vessel and what images (containers) it will set up when executed. The post ends with a "cheat sheet" you can use when working with Vessel providing some common commands.

In a new post to his site Nikola Poša looks at dependency injection containers and shares what he thinks is the right way to use them in your applications.

DIC stands for Dependency Injection Container, which is a tool that manages the construction and wiring up of application services. It closely relates to the letter "D" of a SOLID acronym - Dependency Inversion Principle and is employed to facilitate adhering to the principle.

By their nature, DI Containers are also Service Locator implementations, design pattern that is the exact opposite to Dependency Injection. Because of that, DI Container is a double-edged sword which can mislead you if not used wisely, and ironically bring your code into a state in which there is no dependency injection at all.

He starts off by talking about two kinds of code in an application: core versus assembly. In this case "core" code is the piece of the application that are then used by "assembly" code to make things happen. He suggests that the DIC shouldn't leak into the core and should be put behind a separation between the core code and assembly code. He includes some sample code illustrating what he means and the idea of splitting out the DIC configuration to help that layer clean.