API Platform Conference 2021 - Matt Holt - Better PHP Sites with the Caddy Web Server

[Music] you may not realize it but your php code is only a small part of your site i am not a php developer but i used to be in fact i started all of my web development career with php version 3 and 4 back in the dial up internet days and so i am familiar with php web development but it's just been a while i now write go and that's what i'll be talking about today is my project and go the caddy web server one thing that i learned from writing php code was that no matter how simple and elegant your code is your application is actually really complex it's supported by numerous pieces of infrastructure that have to work together nearly perfectly to make your sites run smoothly and all of that complexity converges on the web server so today i'll show you how and why api platform chose the cadi web server to manage and reduce that complexity if you understand how to truly wield the power of this server you'll be able to do things that you didn't think were possible and your app will scale better and at lower costs with fewer problems than your competitors who might be using different software so when i pulled php developers on twitter a while ago some of the respondents indicated that they didn't really know what made their php sites tick a few didn't even know what the web server was thinking that php fpm was the web server and that's okay as php developers we spend most of our time in php files in fact so much so that some developers pay a premium to not even worry about the web server or the infrastructure and that's fine but it's like it's kind of like leaving the sword in the stone the web server is the central piece of infrastructure supporting supporting your php site when you load your site in your browser it's talking to the web server not your php scripts you would never know it because api platforms docker compose takes care of all this setup for you in fact out of 36 megabytes of documentation text on the api platform site there's only one mention of cadi and that's that's because you spend most of your time in php files but i'll tell you a secret the best craftspersons the masters of their trades know how all the various components work together an expert musician for example is skilled not only with their own instrument but also at leveraging the rest of the orchestra and they're intimately familiar with each player and instrument so that the overall sound is better so if you understand this diagram you'll have a huge competitive and technical advantage over other over others who who may not understand this yet because knowing how caddy works and how it fits in with your php site can help and if you know how to configure it it can help your sites run more smoothly and scale more than you could imagine especially with regards to https so as php developers most of your time is spent over here on the right side of this diagram in your php files but your php files are a step or two removed from the web they don't receive their inputs directly from the clients instead your php scripts get their inputs from the php interpreter which runs in a pool of worker processes managed by a process manager typically php fpm meaning php fast cgi process manager and fast cgi refers to the protocol that's used to communicate with the web server and to populate the environment for your php script that's how you get your server post and get variables your web server will decode those values from http requests that come in from the client over a secure tls connection also managed by the web server and it does this after routing static assets like html and javascript and images away from the php interpreter into loading them from disk to serve the static assets of your site so there's a lot going on here and and this setup is complicated and thankfully you don't have to worry about it too much because api platform takes care of it for you the web server if we zoom in on the central part of this diagram the web server is kind of the part that touches all the other pieces of your site it has to be able to terminate tls so that you can have a secure connection to your site and then it decodes http requests that come in over the wire once it decodes that it has to decide how to handle the request is it going to serve a static file from disk like html or images or css or is it going to send it to your php script if it's going to send it to php it has to be able to convert that payload that http payload into a fast cgi payload so that it can talk to your interpreter meanwhile it also needs to be configured to block attacks to reject mischievous or malicious requests or requests that may hog your resources and also manage things like headers and in production deployments you'll often find the web server managing caching and compression for performance reasons you'll also typically enable logging so that you can have observability and insights into your application and so the web server is this really crucial part of your site especially when you go to deploy web servers will also do a lot to make sure the requests are something your php script can manage and so there's a lot of redirecting or rewriting that happens before your php script even sees anything a redirect and a rewrite are similar a redirect is an external event where the web server responds with an http 300 status and gives the client a new location to retry the request at a different uri a rewrite is similar but it's an internal change that the client never knows about but the web server will perform that rewrite internally to make future processing much smoother and more consistent and we'll show you examples of both of these a little bit later and of course the web server has to be able to proxy to php or serve static files and these are just a few things that the web server does for you and so you can see how if you know how to like how to configure and how to tune this server you will have more power and control over your php application so let me introduce you to the caddy web server you probably are already familiar with web servers like apache or nginx that have been around for decades uh but as i learned this morning caddy is almost exactly the same age as api platform maybe differing by just a few months his first commit was in late 2014. so cadi is a highly extensible self-hosted platform on which you can build and configure and deploy apps which are any long-running service really that you can plug into cadi so you can pull up our website and learn a little bit about it you'll see that it's a 100 open source project it's apache licensed and we call it caddy because it takes care of a lot of the menial or mundane tasks that you would otherwise have to do as a site owner so that you can be more productive and in fact the we call it the ultimate server because it's so extensible and flexible that it can really do anything that you need it to do you can plug in all the capabilities that it needs to have and so you end up with fewer moving parts less that can go wrong less that can break but the caddy project has hundreds of contributors we have millions of downloads and we've secured trillions of of connections on the web significantly caddy is the only web server to use tls automatically and by default so let's talk about this because this is really important as you deploy a site on the internet caddy's flagship feature is automatic https which means that when you tell caddy to service site it assumes https by default not http like other servers so it will automatically obtain and keep certificates renewed so and serve your site over https it's well known for having kind of a gold standard implementation of this feature which i'll talk about why later but it also will scale vertically and horizontally to meet all of your needs as your service grows you can serve tens of thousands of sites with caddy no problem it will manage all the certificates and it also scales horizontally so you can add more instances and they will coordinate certificate management as a cluster automatically and share resources it even has its own internal certificate authority its own pki facilities and services that you can access and configure to operate its own internal you can deploy this internally without relying on a public ca as well another huge benefit of caddy or a huge difference from traditional servers is that with cadi you get more memory safety memory safety is a characteristic of a program to be safe from a whole class of vulnerabilities that exploit memory bugs you might remember in 2014 the heart bleed bug which notoriously leaked the private keys of most of the servers on the internet but caddy is written in go which has higher memory safety guarantees and so this kind of bug is impossible in cadi and so just by deploying caddy instead of a c server your site is already more secure and also because caddy is written in go it's a it's a single static binary meaning that there's no external runtime dependencies you don't even need libc you can simply compile or cross compile cadi in just a few seconds and then rsync it to your server and run the caddy command and your site is up and running with https it's really that easy to deploy you don't even need containers because there are no dependencies in fact we recommend not running cadi in containers because it just adds to the complexity of your infrastructure unless of course you're packaging it for distribution uh with a part of a larger platform just like api platform is that's obviously fine a huge reason that people choose cadi including api platform is because it's highly extensible even the web server is a plug-in and there are dozens of these plugins and they can do any number of things and you'll see that api platform has taken advantage of this with the vulkan and mercure modules which they have written to integrate with caddy to do more for your sites in a simpler deployment these plugins are easy to write especially if you already know go we have documentation on our site for this and it should just take you a couple of hours to to get up and running with a basic proof-of-concept plug-in and and then you can publish it to our site where it will automatically be documented by scanning the code and reading the comments so that everyone can use it and configure it one of my favorite features of the caddy web server is something we introduced in version two over a little over a year ago is its configuration api and this api is a powerful way to manage your web server while it's running caddy's native config format is json and this makes it interoperable with any number of tools and programs you can export it you can traverse into it it has a nice rest api so you can do a get to export and you can do a post put patch or delete to change your config and all changes incur zero downtime they're completely graceful and caddy will also resume with the last config after a power cycle for example and you can see here on this slide an example of how you can use the url to traverse into a part of your config and get or change specific values and so this is really really useful and really unique now if you don't want to use the api the caddy command line also will wrap this up for you nicely so that you can use config files which you may be more comfortable with but this api and the json format make cadi highly conf automatable and programmable now json isn't everyone's cup of tea and so caddy has first class support for what we call config adapters these are plugins that basically take any input format and convert it to json for you so it and this kind of started as a joke but we kept it because it was actually really cool we wanted to kind of put an end to the format wars and how you configure things and so we decided json was a good native format for this but then you can you can write your config in any format that you prefer and caddy will run with it with the proper config adapter so we even have a config adapter for nginx so you can run cadi with your nginx config in some cases which is really cool or if if you want you can you can use a tommel or q or an hcl adapter or yaml if you like pain but most people prefer what we call the caddy file which is a it's a very popular way to configure cadi it's kind of like a mix between an nginx config and a docker file there's no semicolon it's a very simple white space format that the structure is very simple the very top of the file can have an optional block where you configure global server settings and then after that each block contains a site definition which can have one or more addresses or domain names and then in those site blocks you have directives that configure how the site works and that's pretty it's really simple really easy to write and read and you can do most everything with the caddy file that you need to do so we'll show you we'll show you this here in a little bit now caddy has this is important for for you obviously is native php support and fast cgi support and by this i don't mean that caddy is a php interpreter it's not but it does have configuration primitives built specific built specifically for php applications in fact one of our core contributors francis lavoie is a professional php developer and so together we made sure that caddy has a configuration directive just for php sites and we call it php fast cgi and so this one line of config is all that you need in order to run your uh php scripts with with caddy as part of your site um caddy's reverse proxy is it also plugable or extensible and its default transport module which is the thing that doesn't a round trip given a request it gets a response its default transport module is http but it also has a fast cgi transport so you have this native fast cgi integration that works with all of caddy's reverse proxy features now when you use the php fast cgi directive you end up actually we we hide a lot of complexity there's some some php sites require quite a bit of massaging to make it work and so this directive expands out to this equivalent configuration shown here and this is in our documentation because not all php sites conform to modern convention or standards fortunately wordpress symphony and and many other php frameworks do and so you can just use the php fast cgi directive but if your php application doesn't work like those or it might be more legacy or custom then you can use this expanded form as boilerplate and kind of tweak how it works you can see that a few things are going on here we first canonicalize the url with regards to trailing slashes if the request is for a directory and so we append a trailing slash if there's an index file and there wasn't already a trailing slash and that's an external redirect we tell the client to try the request at a different url the next part is a rewrite where if the requested file does not exist we look for index files and this allows your php application to do its own routing at the application level and a lot of php applications do this and so we simply rewrite paths that don't exist as files to your index file and then finally we pass the request to your reverse proxy so that your php script can handle it one benefit of this native integration is performance we had someone shared with us a a huge benefit of switching to caddy from traffic because caddy has native support for fast cgi he was able to proxy directly to the php script instead of needing to proxy to another server that knows fast cgi and this user was able to reduce the latency on their site by 100 milliseconds in some regions just by making that switch so if you were to write a caddy file a config file for your php site it would probably look something like this in its most basic form this is a perfectly valid production config for your wordpress symfony api platform type site and all you need are these four lines the first one is interpreted by caddy to be the site's domain name or address you see that we specify the root folder and that contains your php and html files and then [Music] we have the php and file server directives enabled so that it can serve static resources and do the proxy now this config has a few hidden features one is if you wanted to do some load balancing and and scale your php site horizontally you can just add an address here to the backend a backend address to that php line and because your config file starts with a domain name cadi will automatically serve your site over https for you and i think this is really important to talk about because this is necessary on modern site deployments so all you have to do is make a config file with your domain name minute and as you can see here just by running cadi it will automatically provision a certificate and serve your site over https and redirect http to https for you and this video is about six years old i have never taken the time to record a new one but it still works basically the same way and that is that when you start caddy with a config it will provision certificates for you at server startup it'll load the domain names out of the config it will see if it already has a cert and if it does it will use it if it doesn't it will negotiate a new certificate from a certificate authority like let's encrypt or xero ssl or any other acme compatible certificate authority using the the acme protocol which is a standard that this rfc 8555 that allows certificate authorities to issue certificates and and validate control over dns names and other identifiers in automated ways i could go into a whole nother slide deck about this and how this works but as a site owner the primary thing for you to know is that caddy just needs ports 80 or 443 open to the internet to be able to complete the acme challenge which is how caddy proves that it has control or is listening at your domain name by default cadi will use http or tls challenges which use and require those ports to be open if you can't open those ports or if you need a wild card certificate then caddy can be configured to use the dns challenge with just a single line of config and a proper plugin to integrate with your dns provider and we have dozens of those and more on the way always being contributed now it's easy for anyone to set up a site over https and have it running you can take certbot or acme sh or other tools and stick them on a cron job and be good to go but the moment that things start to get difficult is when infrastructure starts breaking or you need to start scaling or there's revocation events or you there's maybe you don't control all the domain names that you are serving maybe your customers control them and all these challenges uh caddy has a very robust implementation and will keep your site online and will keep managing certificates so i'm going to share with you one of the best kept secrets about the cadi web server that saves a lot of companies thousands of dollars per year probably hundreds of man hours in in maintenance and and labor and that is what we call on-demand tls and this is a useful feature that allows you to manage certificates that for domain names that you don't control so if you allow your customers to bring their own domain name to your service white labeling or or that kind of thing then caddy can handle that no problem the on-demand tls is a special mode of automatic https that will provision certificates on demand at runtime instead of when the server starts so it will obtain a certificate for you on the first tls handshake that requires it it'll it'll hold the tls handshake while it gets a certificate and then a couple seconds later it will finish the tls handshake and serve that certificate and as long as tls client hellos keep coming in for that domain name caddy will keep renewing the certificate and this is perfect when you don't know or control the domain names ahead of time and your config can say static too this does scale really well we know companies using this for tens of thousands of sites and it also works in a cluster and so our users are deploying this all over the globe in a distributed fashion and this is the this is all the config that you need to enable this we configure an endpoint that can prevent abuse so this endpoint might be a php script of yours that checks your database to see if the domain name is associated with a customer and if so you just return to 200 and then caddy will be allowed to obtain a certificate you'll notice that the site address in red is missing a domain name and just has the scheme and that's because we don't know the domain names there might be many and we just know we want to serve https and so this is really all you need so what does this have all to do with api platform well when i asked kevin why they chose to use caddy he said that caddy allowed us to dramatically simplify the setup we provide both in development and in production its main strengths are batteries included and a very easy to extend and we need that for api platform so in api platform version 2.6 they switched from using nginx to caddy and cut the number of containers in about half from eight to four and two of those are optional even while doing this they gained memory safety and automatic https that scales really well and the ability to extend their server much more easily and have vastly simplified your sites because of the switch in fact this is the caddy file that api platform uses it's sorry for the small text but everything is here including http 3 support automatic https which i've highlighted is the server name environment variable and then you can also see their use of their custom mercure and vulcan directives that add that very necessary functionality to our server and then of course the the php fast cgi directive so that your php app can actually be accessed that way so if we were to take something away i would hope that you know that if you really understand your web server specifically the cadi web server you'll have specific technical and competitive advantages for your sites so i encourage you even though that you may not be interacting with your web server directly to actually get started with just playing with it download it and fiddle around with it for a few minutes and have fun with it because we have this great documentation page about how to get started gives you a very simple high-level overview on how to use the server and as you learn to configure it and and as you become expert in in using your web server you will gain more capabilities for your php sites too now before i conclude i do want to draw your attention to the fact that 75 of consumers would feel more likely to recommend or purchase from a company that sponsors open source and i say this because as we'll see here today at api platform conference many open source projects are coming together to make this product work for you and these open source projects are free by nature but still need to be supported and sustained and so it's good to realize that corporations rely on open source and open source likewise relies on corporations i for example work on caddy full-time and i know there are other full-time developers here on open source projects caddy's executive sponsor is zero ssl which that combined with sponsorships on github allow me to develop this full time so i would encourage companies who use open source projects or whose customers use open source projects to advocate for sponsoring those projects to keep them healthy and alive and developed it's also a good look for your business and customers will feel more loyal toward companies that sponsor open source and actually the huge user base of the caddy community is french whether french canadian or from france and other french-speaking communities and i have noticed that over the years and been very grateful for their the french involvement and participation in the project and there's a huge reason that caddy is what it is today and i want to thank you for that um and i wish i could speak your language but uh thank you for listening today and i hope you enjoy the caddy web server thank you matt for this conference are there any questions maybe online first so the questions online were as have been answered by francis so there's no ques no more question online now okay we have a question there um thank you for this awesome presentation of the caddie server i just had well i had actually two questions but the other one is silly so i'm going to start with the first one um first question is is it possible to convert from an external like the you proposed to you suggested that we could use the engineering format as an in as a configuration format is it possible through the api to convert it to json or cadifier maybe yeah good question so all config adapters so the question is uh can the nginx config be converted to caddy file automatically or to json so all config adapters take their input formats and convert it they do output json converting to caddy file could be done but is unnecessary since caddy's native config format is json and even the caddy file is converted to json under the hood and that's the worst code i've ever written in my life did i answer your question you thank you very much a quick question actually you've mentioned that uh caddy is really horizontally scalable i guess as soon as you store certificates you've got these programs like where did the state live can you tell us with more like how how do you achieve that in a cluster yeah good question so how do you how do you scale your certificate management and where do you store the certificates in a cluster so cadi has configurable storage modules and its default storage is the file system so just the local disk now in a cluster that may not work so well for you but fortunately caddy's storage back-ends are extensible they're modular so there's a basic storage api that has methods like load store list delete and so if you can implement a storage module that satisfies this interface of a few methods then you can use that as a back end and so there are storage modules for dynamodb and i think sql databases and console and various other cluster friendly storage locations and of course we rely on these storage locations being secured because they are storing your private keys but all you have to do is configure your caddy instance uh all of the caddy instances to use the same storage module and they will automatically operate in a cluster so it's about one line of config maybe with a plug-in and you're good to go one last question thank you for your talk what is the status of the caddy ingress module for kubernetes because i we are using mostly sometimes nginx one traffic one but last time i searched it was a work in progress so what is the status yeah thanks so pascal asked what is the status of our kubernetes ingress controller so this is a entirely community driven project and apparently is very complicated i am not actually intimately familiar with kubernetes i have been following the development of that project from a kind of a high level view but i know that they are working on it but they need more contributors especially people who are very intimately familiar with kubernetes please help contribute to the the ingress controller my understanding is that it does work it might have some rough edges but it would be great to get that polished and finished up so thank you you

Channel: Les-Tilleuls.coop

Views: 330

Keywords: API Platform Conference, Caddy web server, API Platform, PHP, Open Source

Id: JaEH7Tfzvos

Length: 36min 29sec (2189 seconds)

Published: Tue Nov 09 2021