Using completely custom ddev-webserver base image

[claudiu-cristea]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem?

Sorry, if this issue hasn't been filled in the right place.

At European Commision, we're using https://hub.docker.com/r/fpfis/httpd-php (https://git.fpfis.tech.ec.europa.eu/fpfis/httpd-php) as image for webserver. In our unit we are running more than one hundred (maybe hundreds!) of Drupal sites and all are using this image. This is a constraint, there's nothing we can do about it.

When it comes to a custom webserver image, DDEV states:

It’s unusual to change this, and we don’t recommend it without Docker experience and a good reason. Typically, this means additions to the existing web image using a .ddev/web-build/Dockerfile.*

Actually, this phrase is right now a blocker for DDEV adoption on the project that I'm leading. I'm sure it is blocker also for many other web sites we're building/maintaining in our unit

I have few questions in this regards:

• What makes the DDEV images special? For instance, what brings apache-fpm more compared to a custom image?
• Is the webserver_type pluggable? Can we somehow build our custom webserver_type type, so that we can use our image but still benefit from all DDEV advantages that apache-fpm has?
• If creating a custom plugin (webserver_type) is not possible, what are the aspects we should look in order to still use our custom image?

Describe your solution

See our problem un the previous section.

Describe alternatives

No response

Additional context

No response

[rfay]

You can see the capabilities of ddev-webserver by examining https://github.com/ddev/ddev/tree/master/containers/ddev-php-base and https://github.com/ddev/ddev/tree/master/containers/ddev-webserver

If you can extend your image to have these capabilities, you can use them directly as ddev-webserver. I imagine that's a lot of work.

I see that https://hub.docker.com/r/fpfis/httpd-php has no arm64 versions, which means it won't work on Apple Silicon, and that it has no link to Dockerfile or source/maintenance information.

We have future ideas of being able to use alternate webservers or back-ends in addition to php-fpm and gunicorn, but that's just a glimmer in our eye.

It's possible that you could use your docker image using the techniques in https://github.com/ddev/ddev-contrib/blob/master/docker-compose-services/old_php or https://github.com/ddev/ddev-contrib/tree/master/docker-compose-services/php8_2 - but you'd have to know that since it didn't respect all of DDEV's features, you'd be essentially managing your own image...

[claudiu-cristea]

@rfay,

Thank you, I will explore if possible to extend our image. Lot of work, indeed.

...and that it has no link to Dockerfile or source/maintenance information.

The image source code is here https://git.fpfis.tech.ec.europa.eu/fpfis/httpd-php

[rfay]

Another approach would be to use your image as a custom service (or as an add-on). If you wanted it to use ports 80 and 443, you'd need to change the defaults there so that they weren't taken by the ddev-webserver. This approach seems promising. You get TLS termination and routing from ddev-router, you get all the database types you want to use, and you use your own image. You lose hundreds of DDEV features of course, like multiple PHP versions, etc. But it's a path.

[rfay]

This is a constraint, there's nothing we can do about it

https://git.fpfis.tech.ec.europa.eu/fpfis/httpd-php is quite a simple image. I'm not sure why you are limited to it, I assumed you were stating that it's for policy or political reasons, but being that it's so simple you could in fact integrate it with the features of ddev-webserver, or change its base image to be ddev/ddev-webserver, and you'd hardly have to do anything then (except remove code)

[claudiu-cristea]

@rfay, thank you for support

git.fpfis.tech.ec.europa.eu/fpfis/httpd-php is quite a simple image. I'm not sure why you are limited to it, I assumed you were stating that it's for policy or political reasons

Because is used on the production & CI/CD for all sites from this unit. So, I guess, it's better to use it also in development

(...) but being that it's so simple you could in fact integrate it with the features of ddev-webserver, or change its base image to be ddev/ddev-webserver,

The image is handled by a devops team and we don't have permissions to change that. Or maybe is possible from the our project setup, but I doubt?

[rfay]

Of course, you can build on top of the existing issue as a dev team, but not trying to say that.

DDEV's design goals are about local development, and not about matching hosting images or hosting environments exactly. It's goal is to give developers a local experience that's great. My extensive experience in doing the exact-match local development strategy has taught me that having an exact match is not fundamental.

You say

So, I guess, it's better to use it also in development

but I disagree, I've found that it's not necessary for the vast majority of teams.

[claudiu-cristea]

My extensive experience in doing the exact-match local development strategy has taught me that having an exact match is not fundamental.

Yeah, finally this might be the way.

Thank you for support. I'm going to close this as I think I have all info