All right. 1
Last one and then we're done. 2
All right Vlad. 3
Thanks for waiting so we're on PHP FPM now another PSP user. 4
We're doing PHP FPM Alpine so this is a small image to start and then they load FPM on top of it and 5
then you're setting all of your versions up here. 6
Great. 7
Your directories setting up a bunch of different environment variables that you can override. 8
And then as a whole this is exactly this is HP. 9
This is this is true production HP. 10
Good job on that. 11
That's exactly how mine would look. 12
Now yeah you're setting P2P dependencies and then you're doing a P.K. down here. 13
Now I would probably do versions I would pin versions again down here and then 14
lots and lots of dependencies. 15
I would pin the ones that your app uses in production all of the little stuff like curl and get and 16
stuff. 17
You probably need a pen and you've got your pens down your PSP three so good for that good there. 18
And then even more extensions we got people in there we got all the proper Docker PSP extension installer. 19
So that's good then you're adding a composer user. 20
Great. 21
Right here. 22
So it's important to remember for everyone else that oh look at that in Alpine we cannot pen versions 23
of Alpine packages. 24
I did not know that. 25
That seems odd but I don't have enough information to to do that. 26
So this is an interesting point. 27
And if you watch my doctor over here I mentioned earlier and oh right here on the doctor talk so you 28
can go over to Dockers Web site and watch my talk from Dockercon and I give a 10 minute argument on minimal 29
images versus Alpine. 30
So if you're an HP and you're using the HP 31
images you might consider a Debian minimal image such as a slim uh. 32
Now they just have Alpine so unfortunately they're not using a slim option but with node and some other 33
ones there are slim options and sometimes I prefer those in fact most of them I prefer those over Alpine 34
because the difference is like 50 meg overall total. 35
So it's not I don't do it for size reasons. 36
And then lately with alpine between Alpine security issues the fact that you can't see V scan it very 37
well. 38
And so it actually to me right now is a container. 39
Alpine is less secure than the most current Debian release of a base image. 40
That's my opinion. 41
But I talk more about that and my Dockercon talk. 42
So scroll up in the chat or I'll throw it back in here one more time for those of you that have just 43
joined. 44
But I'm I might consider that if I can't pin versions because I'm just so paranoid because I've had 45
production outages due to version incompatibilities that I pin everything 46
all right. 47
So yeah I got composer and you're changing chose down here. 48
Yep. 49
Change and permissions. 50
Like you need to. 51
Good. 52
Good good you're copying over some of some stuff here. 53
Now you know you can actually make this. 54
Excuse me a copy command and actually now. 55
Never mind. 56
Don't do that. 57
Keep it like it is. 58
You're echoing in a memory limit. 59
That's good. 60
You can overstep. 61
You can set that and override that. 62
You've got a lot of copy files here. 63
It doesn't look like there's a whole lot of opportunity here for consolidating but you could consolidate 64
if they were going to the same directory like right. 65
Well you got some different names on the outs so yeah if you clean it up pretty well. 66
I was just looking for some opportunity to reduce the number of copies of they were doing setup for 67
Cron. 68
Looks like and then doing some last minute shown for the incoming app files. 69
And what did we do. 70
Do we do or copy our our code worked or at folder. 71
You've got a health check in your doctor file a plus. 72
So I love seeing health checks and Doctor files. 73
Cuba daddies won't take advantage of them but doctors swarm will and that way you don't have to depend 74
on an operations person to figure those out later. 75
So yeah at some oh it's a core image. 76
OK so you wouldn't be cupping your ear code into there. 77
Great. 78
And then yeah. 79
And so it looks like what you're doing here is it's up also something that I've used in production many 80
times especially with BHP is you're using supervisor as the base process and it's acting as the unit 81
and then it's launching the various things you need to launch. 82
And I'm assuming that since you have cron and you're gonna have PPF p.m. so there's probably some other 83
stuff here you're doing with supervisor engine X is gonna need to run. 84
So you're going to have at least three processes I bet as some processes and that's the right way to 85
do it. 86
To add sub supervisor in there. 87
Now if you were trying to avoid supervisor it does get tricky on swarm. 88
Oh and this log. 89
Yeah. 90
So I'm not sure why you're running the slug. 91
And you're not using Docker drivers but I'm sure you have a good reason. 92
But if you're using this log to then get them out into Dockers logging using FTD out. 93
That's really what you should be using FTD Aristide's out for logging and ideally not using this log 94
inside the image but that's the recommended best practice. 95
There are a few cases I've seen where it's necessary to use our source log but yeah overall it's a very 96
standard. 97
I think BHP file and it's looking like you're doing a lot of good stuff here. 98
What one thing you could really do if this is a base image. 99
One thing that you could maybe optimize is figuring out a way to combine your base image with your regular 100
images or use multi-stage to reduce any of this unnecessary if you don't need all this stuff right because 101
there's a lot of stuff you're adding in here and it's I don't know whether this stuff is really needed 102
by the production app or if it's just needed to do stuff before the app starts. 103
Right. 104
So now that we have multi-stage and maybe you're using that in your other files in your files that it's 105
coming from the other Docker files but now that we have multi-stage I really like to break out the build 106
dependencies from the production dependencies and basically at the very top I only put in the production 107
and that's the image that I will use at the end and it sort of flows in that way in case of your if 108
you're looking for an example. 109
Again going back to my Docker can't talk I go through a walking example in that Docker can talk here 110
on how you might break out and I think I had four or five stages where I had an initial stage is just 111
for production and sort of the base layer and then I have a dev dependency layer but that layer is never 112
used for production. 113
It's only used for development and all that stuff and then I have a build phase and have a testing phase 114
or stage and then I have the final production stage. 115
So it certainly makes the files look more complicated but I think at the end it reduces complexity of 116
your final image it reduces to attack surface so you maybe are already doing that in your other projects 117
and oh you're saying supervisor has problems with logging so interesting other than that I think it 118
looks like a great Docker file. 119
I think you've got to stop signal in there which I see very rarely I thought cig term was a default 120
but nothing wrong with setting a default in there just to be more literal. 121
But it is pretty cool that you know about that because I rarely see in Docker files because people don't 122
realise that that stop signal option exists so good for you on that because I think a lot is something 123
that my Docker can talk. 124
I talked a lot about was shutting down apps. 125
So the importance of properly shutting down connections. 126
I'm sure it looks like something that you've already known about and learned about in our handling in 127
your app. 128
So good stuff.