 All right. Hello, everyone. Thank you for coming. I'm Abi. I'm a Drupal developer at Prefuse Next. So today, we will discuss what can we gain by moving or migrating from NGINX and PHP FPM to NGINX unit. The first part is we can have more simple and powerful configuration. And the second part is we can containerize our application easier. At the end of the talk, I'll show you a little live demo of the NGINX unit configuration. Before we dive into NGINX unit, let's talk about NGINX, the normal NGINX. So NGINX is a proxy server and static file server. And it's very good at it. Because it is a proxy server, another server needs to run behind it, either HTTP or CGI, USG, or SCGI. And that server that runs behind is the one that executes the code. So NGINX itself cannot run code or programming language. In PHP and Drupal community, running NGINX in front of PHP FPM, which acts as a PyCGR server, is widely adopted. So in this case, FPM is the one that executes the PHP scripts. Compared to normal NGINX, NGINX unit, or we can just call it unit, is an application server that understands the programming language natively, including PHP. This is similar to how the PHP module for Apache works. It was built by the NGINX team, and it is open source under Apache 2 license. There are also other PHP application servers on the rise, like WorkRunner, Swole, WorkerMan, and many more. But most of these servers changes the paradigm of PHP about not sharing state between requests. Let's go into the first part about configuration. NGINX unit configuration is managed dynamically over HTTP via a friendly RESTful JSON API. This means it offers more simplicity and flexibility than NGINX and PHP FPM. By using JSON format, it is more portable because most programming languages support JSON natively. And from the depth of standpoint, this is a huge win because you can create custom scripts, tooling, wrapper, or even interfaces to deal with configuration and manipulate it easily. Because it is an HTTP API, so there are no configuration files, like NGINX code or FPM code. And all the changes to the configuration are graceful with zero interruptions. We don't need to restart or reload the server. Let's see the configuration for each of them. This is what NGINX configuration looks like for a typical Drupal site. This is taken from the official recipe documentation. It has its own syntax for the configuration format. So it will be hard to manipulate it programmatically. The next one is PHP FPM configuration, which uses any syntax. It's more simple than NGINX format. And it's supported by PHP natively, at least for reading the syntax with parse any file and parse any string function, but not writing into any syntax. Unfortunately, it is not very good with nested structures. Now this is what the unit's configuration looks like. I'm sure we all recognize this format. It's just plain JSON. And it's super easy to manipulate it programmatically. Many of the directives in the unit configuration are similar to the NGINX configuration. Take this snippet, for example, is to configure the IP address and ports that the server will listen to. And just like NGINX, which can have multiple servers listen to different ports, units can also do that. Here we can see protection for some files defined by patterns. So if the location of the URI matches the patterns, it will return 404. So the thing is, if you are familiar with NGINX configuration, you won't face many problems configuring NGINX unit. Some parts of the unit's configuration also have similar behavior to PHP FPM. Here the processes are equivalent to a combination of dynamic and on-demand setup of PHP FPM. We can set the maximum and spare children that will be spawned. We can also set the process idle timeout. Or if you want to configure a unit to behave like a static setup of FPM, so this is how we do it. We just put an integer as the process value. Units also allow us to set PHP configuration directly. We can set the path to the PHP configuration file that we want to use. We can also set individual configurations in the admin and user section. The admin section is equivalent to PHP in the system mode, so it cannot be changed at runtime. Well, the user section is equivalent to PHP in the user mode and can be changed at runtime, for example, with any set function. Environment variables can also be easily configured and they can be changed dynamically at runtime. So how to apply unit configuration? To apply configuration changes, we only need to make an HTTP request to the unit's control endpoint. We can use widely available tools like CURL, or we can use any HTTP client out there. One thing to notice by default, unit control is using Unix socket, so it can be only accessed from the same machine. And not all HTTP clients support Unix socket. It can be configured to use IP-based instead when you're starting the unit server. So in making a request, we can upload JSON file containing the configuration, or we can use JSON string as a request body. We can either supply the whole configuration objects, if you want to change only certain parts of the configuration, you can translate the tree in the JSON object into URL pack. For example, if you want to update memory limit in the PHP application option, we want to use this part in the URL. So we can see in the JSON object, there are applications, and then Drupal, and then admin, and then memory limit and its value. So we put that in the URL slash config. This is the root part of the unit's config API, and then slash application, slash Drupal, slash option, slash admin, slash memory limit. And we put the value as a JSON string in the request body. All right, let's get to the second part about containerization. When talking about containerization in PHP, using nginx and fpm, I've seen that the community is divided into two arguments. Should nginx and fpm run in separate containers, or should they run together in a single container? So running nginx and fpm in separate containers requires the PHP application to reside in both containers, either via shared volume that is mounted to both containers or copied to both containers when you're building the image. The other side of the argument is to run both nginx and fpm in a single container. This usually comes with an additional process manager to handle the nginx and fpm surface. If we cannot use two separate containers, for example in platform as a surface environment or some organization policy, so we have to choose the later option. Now with nginx unit, we don't have to worry about that anymore because it is only one surface, so one container is enough. We can mount the application to the container if we want, or we can copy the application to the container when building the image. So it fits all our needs, whichever it is. Units provide a Docker image for PHP. So you can use it as it is, or you can use it as a base image. The base image itself is based on PHP CLI Docker image. So it's a Debian. You can install PHP extension like you install extension with the official PHP Docker image. If you use something different than official PHP Docker image, so you can replicate how unit was installed in its base image. Units also provide an easy way to initialize configuration in Docker. So you just put your configuration in JSON file, copy it into Docker entry point directory, and the entry point will upload that file to the Units end point when the container running for the first time. I will show you a little demo. I need to do some changes in the display here. Bear with me. So the first thing, let's try to start our unit server. Here I use the control argument to use IP base instead of Unix socket so we can make HTTP requests easier. Let's start it. OK, let's start now. I also have Drupal site installation. And I have the config here. It is the units config for Drupal site. They have example configuration in their documentation. So you can use it and customize it based on Units. So let's see our unit configuration. We make HTTP request and slash config. This is the root part of the config API. So the configuration is there. Let's check it. Here I have a Drupal site installation with Yumami demo. We can see here the web server is unit with its version. We can also see here we have the HP configuration memory limit with 128. So let's try the memory limit. We make a put request to the Units control endpoint to the application named Drupal. And it's PHP option in the admin section. And the memory limit, we change the value. Let's try to change its value to 256. Reconfiguration done. Let's verify it. The configuration is updated in the Units endpoint. So let's see what happened. You can see now the memory limit is 256. So we don't need to restart the server or reload the server. It happens restfully with zero interruptions. I also made a custom module for this demo to interact with the Units control endpoint. So here we have memory limit filled with the value of 256. This is taken directly from the Units endpoint. So let's try to change the memory limit again. Let's change it back to 128. Reconfiguration done. Let's verify again. It's updated. Let's see what happened here. It's also updated in the status page also. So now let's see, change the configuration directly from the Drupal admin UI. And let's see what happens. Let's change it to 256. Reconfiguration done. Let's verify that again in Units control. Yep, it's updated. Let's check in status page also. Now it's 256. Let's get back to the slide. Just ignore this. So the demo for my example is very useful if you want to build something according to our needs. For example, if you want to allow developers or operations to change PHP configuration without giving them access to the server, so we can build interfaces for them, and we can utilize Drupal Powerful Role-Based Access Control and its permission system to secure it, and they won't have to restart and reload the server. All right, to summarize, we can use Engine X unit to replace Engine X and PHP FPM with very little to lose while allowing us to gain simplicity, flexibility, and many powerful possibilities of us by the unit. The configuration and behavior are similar to Engine X and FPM, so you won't face many problems if you're migrating. If you are using more advanced features of Engine X that are not available yet in the unit, you can always use Engine X as a proxy and units as the upstream server. In terms of containerization, the unit is more straightforward than Engine X and FPM and covers more cases. And having said that, we are not using unit in previous necks for production yet, so at this stage, this is part of experimentation and it's a proof of concept. All right, that's it from me. Any questions? So for the performance page parking? OK, hold on. Before questions, I will need my friends, Eric, to help me. He's English native speaker, which can speak my native language very good, so thank you, Eric. Have you done the performance page parking comparing like the FPM class and units of the unit? What are the benchmarking like? What do you mean by benchmarking Engine X and FPM? I haven't done benchmarking myself, but there are some various benchmarks in the internet with various results. So there are some results that unit is better than FPM. There are also results that are kind of similar between units and FPM, but I haven't seen in which result that unit is worse than FPM, so at least is similar performance with FPM. I haven't explored the topic deeply, but I noticed a couple of issues on Drupal that says that, generally, the behavior of the applications and the languages with the application server is quite different to the PHP and how we tend to bootstrap for every request to all the environment set up and all of this stuff. Have you tested Drupal extensively in the unit? How does that behave? Is it just up and running, or do we still need to fix something inside the unit? We've needed some budget before, but then we'll move on. It should be me and Aleppo. Yeah, so unit is different with some application server that keep the state. So when you bootstrap the first request, so the state is just leave when the server leaves, it's different than that unit. So unit is more like PHP model for Apache. So yeah, it's very similar with how NGINX and FPM works. So you won't have many problems with that, especially with Drupal. So I have using units in previous organizations, but not for production and for client and client. So it's using part of our internal system. So it works well just like NGINX and FPM with no trouble at all. What's its database for offline? I noticed you were using SQL live, just then. Does it take more entity, then in my SQL, et cetera? We spoke with Dr. Marshmallow, my friend. Yeah, just because install the Imami demo with the Drupal script. So yeah, it doesn't matter as long as it's supported by Drupal. So it just works normally. OK. Thank you, everyone.