Bootiful Podcast Appearance

I recently got the opportunity to talk with the amazing Josh Long on his podcast, Bootiful Podcast. It was a great time and a fun conversation. We started from the beginning and talked about all things containers, Docker, Buildpacks, Paketo, and of course, Spring & Native Images.

If you're new to buildpacks or looking to give them a test run, this is a great place to start. We covered a lot of the concepts and questions people frequently ask. It was also great to talk about some of the improvements that we've recently added into the Java buildpack. For example, we recently added support for UPX compression of native images and the ability to use Tilt with buildpacks for microservice development.

Please check it out! You won't be disappointed. Josh is always entertaining, and hopefully you'll come away having learned something new.

Recent Happenings

I have over the years done a lot of work with buildpacks. Both on Cloud Foundry and now with Cloud Native Buildpacks. This year I've been fortunate enough to start a job at VMware working on them full time, which I'm pretty excited about.

I am primarily working to develop the Java-related Paketo buildpacks, as well as contribute to the Buildpacks project & to also maintain the Java Cloud Foundry buildpack.

To support this effort, I'm going to try and start writing more about these efforts. What's new, what's cool and more about how to use buildpacks.

To kick this off, I have a post I wrote up for work: Container Images the Easy Way with Cloud Native Buildpacks. If you're new or wondering about buildpacks, this is a good place to start. It talks about how buildpacks can help you and gives some comparison to using Dockerfiles to build your container images, something many people are doing at the moment.

I also had the opportunity to be on Tanzu.tv and discuss similar topics, so if you'd rather watch a video than read, you can find some of similar info about buildpacks there.

PHP Cloud Native Buildpack Updates

It's been a little while since I've posted an update on the PHP Cloud Native Buildpacks. The good news is that lots of progress has been made. We've basically achieved feature parity with the old PHP buildpack and I believe the PHP CNB's should be working for most apps now!

If you're coming from the old PHP buildpack, there are some differences. This is basically a major version bump, so it was an opportunity to make a few breaking changes that we believe will generally improve the user experience. Check out the migration documentation for details on what's changed.

Here's a quick demo of what you can do.

1. Start out by cloning the Symfony Demo app.
2. Add a file to the root called buildpack.yml. In that file, add the following:
   
   ---
   php:
     webdirectory: public
   
   This will tell the buildpack the location of the files that we want it to serve.
3. Create the folder .php.ini.d and in it put the file symfony.ini. Inside that file, add the line: variables_order = "EGPCS". This tells PHP that we want the $_ENV superglobal. I'm not a Symfony expert, but it seems to be required for Symfony to configure itself from actual environment variables, which we'll be doing.

These are the only changes we need to make for the demo app to work.

Next up, install prerequisites. You only need to do this once.

1. If you don't have the pack cli install, go do that now.
2. If you don't have docker installed, do that.

Now, from the root of our application directory we just run pack build -b paketo-buildpacks/php -e APP_ENV=prod symfony-5-demo to build an image.

Breaking it down:

• pack build is the command to build an image from Cloud Native Buildpacks
• the -b flag indicates which Cloud Native Buildpacks to use. In this case, we point it to the meta buildpack for PHP. Meta buildpacks are collections of Cloud Native Buildpacks.
• the -e flag set an environment variable picked up by Symfony during build. It tells it that we're doing a production build.
• the last bit is the image name we want to create

Lastly, we can run our image with docker run -e PORT=8080 -p 8080:8080 -e APP_ENV=prod symfony-5-demo.

Breaking it down:

• docker run will run your image
• -e sets the PORT environment variable which tells the buildpack what port it should have the app listen to.
• -p tells Docker that we want to expose port 8080. This needs to match the value of PORT so that the port on which the app is listening matches the port on which docker is allowing traffic.
• the second -e again tells Symfony that we're running in production mode
• the last bit is the image name to run, this should match the image name we used with pack build.

At this point, you can go to http://localhost:8080/ in your browser and access the Symfony Demo App that's been built with Cloud Native Buildpacks and is running inside your Docker container.

Some final notes:

• By default, it's going to run with PHP's built-in web server. That's not very "production", so we can add Nginx or Apache Web Server by adding the line webserver: httpd or webserver: nginx to buildpack.yml (add it under the php: block). That's it. No server configuration files required. The PHP Cloud Native Buildpacks handle it all for you.
• The first time you run pack build, it will be slow. It needs to download resources like the build & run images, plus of course it needs to download PHP itself. After the first time, things will speed up dramatically. The images will exist locally and PHP downloads are smartly cached. With downloads cached, a full build takes about 10 seconds on my laptop.

That's it. Hope you all enjoy. Feel free to raise any feedback on Github.

PHP Cloud Native Buildpacks Now in the Official Builder

In my previous post, I talked about how to use the PHP Cloud Native buildpacks. It was not super tricky but required some manual work to set up. This is because the PHP CNBs were not, at the time, part of an official builder.

What's a builder? It's basically an image containing a bunch of CNBs, all ready for your use. See this link for more details.

If you are to run `pack suggest-builders`, then you will see the list of official builders. At the time of writing, that is Heroku, Cloud Foundry (bionic) and Cloud Foundry (cflinuxfs3).

$ pack suggest-builders
Suggested builders:
    Heroku:            heroku/buildpacks:18            heroku-18 base image with buildpacks for Ruby, Java, Node.js, Python, Golang, & PHP
    Cloud Foundry:     cloudfoundry/cnb:bionic         Ubuntu bionic base image with buildpacks for Java, NodeJS and Golang
    Cloud Foundry:     cloudfoundry/cnb:cflinuxfs3     cflinuxfs3 base image with buildpacks for Java, NodeJS, Python, Golang, PHP, HTTPD and NGINX

Tip: Learn more about a specific builder with:
    pack inspect-builder [builder image]

Notice how PHP is now included in the Cloud Foundry cflinuxfs3 builder.

So now, instead of all the work I had you doing in my last post, you can just run `pack build --builder "cloudfoundry/cnb:cflinuxfs3"`. The builder will automatically select the PHP CNBs, because it sees you're trying to build a PHP app. The result will be an image you can run with `docker run -it -e PORT=8080 -p 8080:8080 image-name`, just like in my previous post.

That's it! If you'd like to understand the output a bit more, keep reading. Otherwise go and enjoy!

---

If you're curious about the output, the interesting new bit is the DETECTING phase. In the previous post, we manually specified just the PHP CNBs, so that's all you'd see in the output. Now, we see many CNBs running, but only the PHP CNBs will be selected and actually run at build time.

===> DETECTING
[detector] ======== Results ========
[detector] skip: org.cloudfoundry.archiveexpanding@1.0.0-RC03
[detector] pass: org.cloudfoundry.openjdk@1.0.0-RC03
[detector] skip: org.cloudfoundry.buildsystem@1.0.0-RC03
[detector] pass: org.cloudfoundry.jvmapplication@1.0.0-RC03
[detector] pass: org.cloudfoundry.tomcat@1.0.0-RC03
[detector] pass: org.cloudfoundry.springboot@1.0.0-RC03
[detector] pass: org.cloudfoundry.distzip@1.0.0-RC03
[detector] skip: org.cloudfoundry.procfile@1.0.0-RC03
[detector] skip: org.cloudfoundry.azureapplicationinsights@1.0.0-RC03
[detector] skip: org.cloudfoundry.debug@1.0.0-RC03
[detector] skip: org.cloudfoundry.googlestackdriver@1.0.0-RC03
[detector] skip: org.cloudfoundry.jdbc@1.0.0-RC03
[detector] skip: org.cloudfoundry.jmx@1.0.0-RC03
[detector] pass: org.cloudfoundry.springautoreconfiguration@1.0.0-RC03
[detector] Resolving plan... (try #1)
[detector] fail: org.cloudfoundry.jvmapplication@1.0.0-RC03 requires jvm-application
[detector] Resolving plan... (try #2)
[detector] fail: org.cloudfoundry.jvmapplication@1.0.0-RC03 requires openjdk-jre
[detector] Resolving plan... (try #3)
[detector] fail: org.cloudfoundry.jvmapplication@1.0.0-RC03 requires jvm-application
[detector] ======== Output: org.cloudfoundry.yarn@0.0.24 ========
[detector] no "yarn.lock" found at: /workspace/yarn.lock
[detector] ======== Results ========
[detector] pass: org.cloudfoundry.node-engine@0.0.46
[detector] fail: org.cloudfoundry.yarn@0.0.24
[detector] ======== Results ========
[detector] pass: org.cloudfoundry.node-engine@0.0.46
[detector] fail: org.cloudfoundry.npm@0.0.29
[detector] ======== Output: org.cloudfoundry.pipenv@0.0.14 ========
[detector] no Pipfile found
[detector] ======== Results ========
[detector] pass: org.cloudfoundry.python@0.0.20
[detector] skip: org.cloudfoundry.pipenv@0.0.14
[detector] pass: org.cloudfoundry.pip@0.0.20
[detector] Resolving plan... (try #1)
[detector] fail: org.cloudfoundry.pip@0.0.20 requires requirements
[detector] ======== Results ========
[detector] fail: org.cloudfoundry.conda@0.0.13
[detector] ======== Output: org.cloudfoundry.dotnet-core-conf@0.0.20 ========
[detector] *.runtimeconfig.json file not found
[detector] ======== Results ========
[detector] fail: org.cloudfoundry.dotnet-core-conf@0.0.20
[detector] ======== Output: org.cloudfoundry.go-mod@0.0.18 ========
[detector] no "go.mod" found at: /workspace/go.mod
[detector] ======== Results ========
[detector] pass: org.cloudfoundry.go-compiler@0.0.20
[detector] fail: org.cloudfoundry.go-mod@0.0.18
[detector] ======== Output: org.cloudfoundry.dep@0.0.17 ========
[detector] failed detection: no Gopkg.toml found at root level
[detector] ======== Results ========
[detector] pass: org.cloudfoundry.go-compiler@0.0.20
[detector] fail: org.cloudfoundry.dep@0.0.17
[detector] ======== Output: org.cloudfoundry.php-composer@0.0.16 ========
[detector] no "composer.json" found in the following locations: [/workspace/composer.json /workspace/htdocs/composer.json]
[detector] ======== Results ========
[detector] pass: org.cloudfoundry.php-dist@0.0.28
[detector] skip: org.cloudfoundry.php-composer@0.0.16
[detector] pass: org.cloudfoundry.httpd@0.0.18
[detector] pass: org.cloudfoundry.php-web@0.0.18
[detector] Resolving plan... (try #1)
[detector] skip: org.cloudfoundry.httpd@0.0.18 provides unused httpd
[detector] Success! (2)

See how they all fail, until you get down to the PHP CNBs. Then you see Success!.

Then just like the last time, we see the PHP CNBs running during the BUILD phase.

===> BUILDING
[builder]
[builder] PHP Buildpack 0.0.28
[builder]   PHP 7.2.22: Contributing to layer
[builder]     Downloading from https://buildpacks.cloudfoundry.org/dependencies/php/php7-7.2.22-linux-x64-cflinuxfs3-c9315fce.tgz
[builder]     Verifying checksum
[builder]        Expanding to /layers/org.cloudfoundry.php-dist/php-binary
[builder]     Writing PATH to shared
[builder]     Writing MIBDIRS to shared
[builder]     Writing PHP_HOME to shared
[builder]     Writing PHP_EXTENSION_DIR to shared
[builder]     Writing PHP_API to shared
[builder]
[builder] PHP Web Buildpack 0.0.18
[builder]   Configuring PHP Script
[builder]   PHP Web 173b6da1f1b7b7a59af0c2ebcfe1c4ea4b183063a90b92f1f2ae6d8a9ebb0bfd: Contributing to layer
[builder]     Writing PHPRC to shared
[builder]     Writing PHP_INI_SCAN_DIR to shared
[builder] WARNING: `app.php` start script not found. App will not start unless you specify a custom start command.
[builder]   Process types:
[builder]     task: php /workspace/app.php
[builder]     web:  php /workspace/app.php

That's all there is too it.