Where to override ENTRYPOINT ?

[tiredofit]

Where to override ENTRYPOINT ?

[tiredofit]

Thanks for the sponsor :)

I just added the following to the base images (alpine and debian)
CONTAINER_POST_INIT_SCRIPT = Put multiple scripts seperated by commas to execute before the overall container finalizes its init process.
CONTAINER_POST_INIT_COMMAND = As Above but execute a singular command without having to insert a script somewhere. Seperate by commas.
NGINX_POST_INIT_SCRIPT = Put multiple scripts seperated by commas to execute before the overall container finalizes its init process.
NGINX_POST_INIT_COMMAND = As Above but execute a singular command without having to insert a script somewhere. Seperate by commas.
PHP_FPM_POST_INIT_SCRIPT = Put multiple scripts seperated by commas to execute before the overall container finalizes its init process.
PHP_FPM_POST_INIT_COMMAND = As Above but execute a singular command without having to insert a script somewhere. Seperate by commas.

So lots and lots of flexibility here on which way you want to use it. I included these multiples here just in the event that a child image clobbers some of the parent images custom environment variables if you are looking to use the image for complex stuff. I can already see this working in so many cases for my environments.

Should be available for you by tomorrow 8am PDT - Github build process is slower than I'd like and I have to remind myself to be around to trigger the next images builds after the first ones build and its now the end of my office day. Let me know how it works out.

FWIW - If you are doing some laravel work I have some real interesting stuff in some private images that you may want to take advantage of in terms of cache and config busting and also recompiling assets in a "development" style container. One simply needs to flip an environment variable from STAGE=develop to STAGE=production to make it exit it out of this development style mode. Let me know if of interest and I can clean it up for public consumption over the next few days.

[tiredofit]

I think it should work with sail - Basically it is a series of extra scripts that run watchers when files are updated (css mostly) to recompile if you are doing things with Tailwind. Note, I know little to nothing of laravel other than maintain a few images and think its a pretty elegant framework, so I'll have to ask a couple people to find out more, but I'll definitely put this together and integrate it into the image in the near future - it may turn into it's own "laravel" image just to keep things clean but still relying on all the same functionality at this one. Lets see.

As for the amount of images, I question that myself. Things sort of grew with the first one tiredofit/wordpress in 2017 and then grew from there. I started doing some consulting for an organization that was in desperate need for disaster recovery and couldn't didn't have any instructions on how to get their applications going again, so I started down that path.. Eventually I realized it would be good to build a few base images with common functions so that I could quickly roll out images. That's where we've ended up today and while there are the tricky parts to understand the applications in question the base images and the framework is what makes it easier for me. Of course it still is maintenance, but each and everyone is used in a production environment today, so that gives me motivation. It's probably not the best use of my time overall, but its what keeps my brain ticking as opposed to being lost in the business world 100%.

[tiredofit]

I can insert what I do in some other images to accommodate for "custom scripts"

The premise would work like this:

• Drop file in /assets/custom/01-artisan.sh

Inside that Script it could look like so:

#!/command/with-contenv /bin/bash

cd /www/${NGINX_WEBROOT}
sudo -u ${NGINX_USER} php artisan config:cache`
$(date) > /www/html/date.log

This would execute the script before nginx/php-fpm runs accomplishing what you are after.. I do have to watch out though as my dependent images also have this snippet for /assets/custom-scripts and we wouldn't want to run it twice.

Perhaps I can include an environment variable that can call a specific script somewhere on the filesystem as such:

PHP_FPM_POST_SCRIPT="/somewhere/yourscript.sh
which would allow us to avoid the snippet in this image and let it work in the child images.

[chuckienorton]

Yes PHP_FPM_POST_SCRIPT would be brilliant! I'm sure people would use it since most articles i read recommend those types of scripts.

We'll try your first method out for now and look for any more official changes if they're ever pushed.

Thanks for everything @tiredofit !!!

[chuckienorton]

Wow you're awesome!

First off - yes i'll definitely look for the changes tomorrow!

Second - i think i'd definitely be interested IF it would work well with docker-compose and laravel sail, since that's what I've gotten used to.

BTW - How do you keep up with so many repos?

[chuckienorton]

... It's probably not the best use of my time overall, but its what keeps my brain ticking...

This could be said of huge parts of every moment of my life.

Also, and I'm just guessing here, but since laravel is super popular, and a lot of developers are just jumping into the docker ecosystem, you might find an audience there. I'd definitely recommend naming it laravel for search purposes if nothing else.

[chuckienorton]

I'm closing this since we are able to confirm that PHP_FPM_POST_INIT_SCRIPT is working great!

Thanks!