Multiple processes to run frontend & backend

[keskad]

Hi,

I need to run nginx & django/gunicorn/uwsgi to serve both static files and Python backend.
The team says they are having complex redirection rules in NGINX and don't want to change it to something else.

I already used NGINX buildpack and know how to use it, I have also used cpython and nodejs buildpacks, but I don't know how to make two entrypoints working together.

I'm also a PHP developer and I noticed there is a php-start buildpack which runs NGINX and PHP-FPM, but I noticed it is not reusable.

Is there a way to run at least two processes at once?

[dmikusa]

The general recommendation is to not run multiple processes in the same container. This isn't buildpack-specific advice but general advice on using containers. When you add multiple processes you complicate things, like scaling and failure handling. It also mixes concerns. Nginx is your proxy/gateway, that's part of the networking layer, not your app. If you stuff all that into one container, then you're making your deployment less flexible. If for example, you want to switch to another proxy/gateway, then you need to rebuild your containers and deploy everything again. If you have them separate, you swap out your proxy/gateway, and the backend never even knows.

What I'd suggest you try is two builds. First, build an nginx container with your nginx.conf file. It should be trivial to get that container to build, but you might need to adjust your nginx config if it assumes your backend server is running on localhost. The nginx buildpack supports env variable substitution in your config file, so if you make the backend target an env variable it can make your container very flexible. Exactly what you pass in as the value for that env variable will depend on your runtime orchestration of the containers. If for example, you are using Docker Compose, you can pass in the service name of your backend service and send requests that way. Essentially you need to see what your container orchestrator provides in the way of service discovery and use that.

Then do a second build with just your Python backend. The Paketo Python buildpack should handle building that correctly. Maybe someone from @paketo-buildpacks/python-maintainers can comment, but I believe it should support gunicorn/uwsgi deployments.

As far as the PHP setup goes, that's a little different. The primary way you deploy PHP is with PHP-FPM, but PHP-FPM is not a web server. It's a separate protocol so we pair either Nginx or HTTPD with it because some container orchestration systems expect HTTP traffic.

If you wanted to do something similar to that with Python, you'd be looking at a custom buildpack. It could reuse most of the existing Python buildpacks, but you'd need a custom buildpack that would integrate Nginx and add process types to start up both processes. Remember how I said that running multiple processes in the same container is tricky? That's going to come into play with the process types. You'd probably need to include some sort of process manager to make sure that you handle different failure scenarios correctly. For example, what if Nginx dies but your app does not? or vice versa? If you don't have your error handling set up to terminate the container, then you can get into a situation where your containers are up and "healthy" but not healthy.

Hope that helps!

[keskad]

Thanks for your reply :)

I know about the general recommendation, that's a container's theory, but I have a practical use case.
The theory mainly is about that you should not put e.g. Redis or Database with your application inside single container, but that's not the case. I'm talking about a consistency, single app but written in multiple technologies, that's not a microservice case - just a frontend + backend from same repository.

It depends on how do you look at complete application and how your infrastructure looks like 😎

1. The application is a frontend + backend, one does not work without other. So it's a complete application. It does not make sense to e.g. scale nginx serving index.html + js + images. That's a reason to keep it together.

2. Web application in my opinion should expose itself on a HTTP port, so the Ingress Controller on the Kubernetes cluster could talk with it. So a complete web application in some cases would be e.g. PHP-FPM / Python / other + NGINX 🌞

3. Two builds makes no sense, because I have GitOps releases. One repository = one release. For consistency frontend + backend in my opinion should be relaesed together, not separately 🙂

4. I do not consider simple NGINX exposing frontend at "/" and backend at "/api" as a networking layer. It lacks TLS support, WAF configuration and many complex things. Those things are indeed on the network layer that's called Ingress Controller and Load Balancer 🙂

[dmikusa]

Sorry if I offended, I start with that advice because we can't assume prior knowledge when people post. You just don't know someone's background. That advice is there for good reason, so it helps to start with it and level set. I understand we live in a non-perfect world where you sometimes have to take a practical approach to make things work. You obviously know your situation the best.

If you want to go the route you mentioned, you'll need something to run multiple processes in one container. You need a way to kill everything when one process stops working or dies, like health checking within the container. You also need something to aggregate logs in a way that still makes sense. Because of the common advise most container orchestrators expect or assume your container has only one process. For best results with multiple processes, you'll want it to work that way even though you have many.

I haven't used it but multirun might be one way to do that.

For the PHP buildpack, we wrote a small Go binary. It is ultra simple (and not PHP-specific) but provides what is necessary to have the processes all function as one unit. It also streams logs to STDOUT annotating them with process info so you can separate the log messages. It has very simple health checking, only ensuring that the processes stay up and running though. If that is OK in your scenario, it might be something you could use in a custom buildpack. Just throwing it out there. There are many tools that can do this, anything that checks those boxes should work well.

[keskad]

Regarding custom buildpack I was thinking about packaging multirun as a buildpack to provide entrypoint that calls Python + NGINX, but my client does preffer this way and I'm looking for simpler options.

[dmikusa]

You could certainly make a custom buildpack to install multirun. You might also consider using the Apt Buildpack assuming that multirun is available as a package or Deb file. That would save some work and prevent you from needing a custom buildpack to install it.

You could also use a Procfile if you don't want a custom buildpack just to set the process types. The Procfile buildpack, basically takes a Procfile and turns the commands in that file into process types.

If you include a Procfile with your app and use the Apt buildpack to install multirun or some other process manager, maybe you can get by without any custom buildpacks. Not 100% sure though cause you still need something to pull in Nginx.

If you go the route of a custom buildpack, and haven't already, check out the PHP Start Buildpack. The README there explains the buildplan we use in PHP to pull everything together pretty well. That's also the glue that pulls everything together, so you might be able to swipe some code from there.

[keskad]

I dont feel offended at all :), thanks so much for your response. The good practices you mentioned could be perfect for other readers which may possibly dont know that, so thats ok :)) I think way with apt (package manager at all) may be difficult due to air gapped environment in my case, but the Procfile approach could be useful. Regarding custom buildpack I was thinking to avoid using Go. I noticed that example on buildpacks.io on how to build own buildpack is in Bash. I think installing Multirun should be simple enough, then I could use Procfile for the rest. My client may not be ready to learn new language I think currently, they have everything in Python :) Is writting a buildpack fully in Bash and using it with Paketo builder possible? :) niedz., 10 gru 2023, 01:30 użytkownik Daniel Mikusa < ***@***.***> napisał:

…

You could certainly make a custom buildpack to install multirun. You might also consider using the Apt Buildpack <https://github.com/dmikusa/apt-buildpack> assuming that multirun is available as a package or Deb file. That would save some work and prevent you from needing a custom buildpack to install it. You could also use a Procfile if you don't want a custom buildpack just to set the process types. The Procfile buildpack <https://github.com/paketo-buildpacks/procfile>, basically takes a Procfile and turns the commands in that file into process types. If you include a Procfile with your app and use the Apt buildpack to install multirun or some other process manager, maybe you can get by without any custom buildpacks. Not 100% sure though cause you still need something to pull in Nginx. If you go the route of a custom buildpack, and haven't already, check out the PHP Start Buildpack <https://github.com/paketo-buildpacks/php-start>. The README there explains the buildplan we use in PHP to pull everything together pretty well. That's also the glue that pulls everything together, so you might be able to swipe some code from there. — Reply to this email directly, view it on GitHub <#230 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC25M7KOVO6OALW6W3MADDYIT7CTAVCNFSM6AAAAABAKTFD7GVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TQMBZGUYDC> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[dmikusa]

I think way with apt (package manager at all) may be difficult due to air gapped environment in my case

Ahhh, I see. Yes. That makes things trickier. Apt buildpack would not be easy to get to work. I think you could point it to an apt repo on your own network technically, but that's probably a lot of work and not worth it.

Regarding custom buildpack I was thinking to avoid using Go.
Is writting a buildpack fully in Bash and using it with Paketo builder possible? :)

That's not a big deal. We use Go at Paketo because we're maintaining a large set of buildpacks. The choice of Go is nice cause you get good testing capabilities, code that's fairly easy to maintain, it's fast and generates self-contained binaries are relatively small. It's not critical though, you can absolutely make buildpacks in any language including Bash.

When you use a language like Bash or even Python, the catch is that you need to make sure that the runtime you need is included in the Buillder images. With Paketo, we include Bash in all of our Builders, it is also available at runtime in the full & base builders, but we don't include Python in the builders. So if you wanted to use Python, you'd need to install it first (possibly with another buildpack that runs first).

If you're interested in the Python route, one of the guys on the buildpack team has a library for that called python-libcnb. That might save you some time. If you want to go the bash route, the tutorial on the buildpacks.io site is a good way to get started.