Leveraging Standard Buildpacks to Migrate Not-So-Standard Apps

Conﬁdential │ ©2021 VMware, Inc.
Leveraging Standard
Buildpacks to Migrate
Not-So-Standard Apps
SpringOne 2021
Matthew Campbell
& Brandon Blincoe
VMware App Navigator Services

Confidential │ ©2021 VMware, Inc. 2
This presentation may contain product features or functionality that are currently under
development.
This overview of new technology represents no commitment from VMware to deliver these
features in any generally available product.
Features are subject to change, and must not be included in contracts, purchase orders, or sales
agreements of any kind.
Technical feasibility and market demand will affect final delivery.
Pricing and packaging for any new features/functionality/technology discussed or presented, have
not been determined.
The information in this presentation is for informational purposes only and may not be incorporated into any contract. There is no
commitment or obligation to deliver any items presented herein.
Disclaimer

Abstract
Heritage apps come in all shapes and sizes. The wheel of technology rolls on and many of us find
ourselves responsible for valuable software built with technologies that make us uncertain how to
leverage modern cloud platforms.
We’ve been helping customers tackle their not-so-standard apps for years, and buildpacks have
become an indispensable tool in our toolbelt. The big question is: what do you do when you don’t have
a buildpack that fits your app? We’ve found there’s almost always a standard buildpack that applies with
a little work. In this talk, we’ll run through a few apps from our history, talk through our process of
experimentation, and figure out how to get them running on Cloud Foundry together.
This talk is for the app practitioners responsible for moving to the cloud but aren’t sure their app will fit.
You’ll be surprised by the ways you can leverage just a little refactoring and the magic of buildpacks to
help you get to the cloud in a standard way without a rewrite.

Who We Are
Application Modernization Practitioners
Matthew Campbell
Solutions Architect, VMware App Modernization
Brandon Blincoe
Program Manager, VMware App Modernization
LinkedIn: mtthwcmpbll
Twitter: @mtthwcmpbll
Web: snowfort.com
LinkedIn: brandonblincoe
Twitter: @brandonblincoe
Web: bblincoe.com

Agenda Why Talk About This Now?
Navigating Our Way on the Modernization Journey
Let’s Walk Through An Example
Our Replatforming Journal
When Should You Replatform?
Decide Based on Business Needs
Q&A
A Breakout Session
Join the Slack channel!
#session-migrating-not-so-stan
dard-apps-with-buildpacks

Why Talk About This Now?
Where we’re all at on the modernization journey

Many of us ﬁnd ourselves
responsible for valuable
software built with technologies
that make us uncertain how to
leverage modern cloud
platforms.

The Last Hundred Yards
Our work with customers involves being strategic about portfolios big and small, modernizing big
systems, replatforming old and new software, and deciding when to invest in writing new code.
App modernization is a journey, and we’re seeing more and more that customers are already well
on their way.
You’ve done easy stuff.
You’ve done some big scary stuff.
What about weird stuff?
Ooooo, a cloud haiku!

Buildpacks are Powerful Tools For the Whole Organization
● They give you an opinionated target to aim for
● They take a little (or a lot) of work oﬀ your teams
● They provide a common baseline of deployment for your organization
● They reduce the number of teams or people needed to patch security vulnerabilities
● They’re vendor agnostic a growing community of support

Let’s Walk Through An Example
Our Replatforming Journal

➜ open http://apptx.wtf
Today, we have a circa-2000’s Perl
web app running on Apache httpd
inside of a Virtual Machine...argh!
We want this site to get the
beneﬁt of running in our Cloud
Foundry platform, but we can’t
aﬀord to rewrite it today. Let’s
get started!

A Map of the Production Deployment
This is where our application
lives (we think). It’s all of the
stuﬀ that makes our site
diﬀerent than some other
rehash-based site.

➜ ls
Let’s take a look around our
development machine...

➜ cf target
Am I logged into the Cloud
Foundry?

➜ cf buildpacks
What buildpacks are available?

Can I just cf push it?

➜ cf push rehash
Just as we expected, there’s no
buildpack that knows how to
detect this random collection of
web server conﬁguration.

➜ are there custom buildpacks out there?
This one looks promising?
And old.

➜ cf push rehash -b https://github.com/...
Pushing with this buildpack
fails...

➜ cf logs rehash
It looks like the buildpack is
expecting some weird stuﬀ on
the ﬁlesystem.
I’m not going to chase this too
far, I’m mostly just testing the
water for an out-of-the-box
solution.

Is there a opinionated
buildpack that builds
the environment we need?

What do we mean by an opinionated buildpack?

➜ vi manifest.yml
Let’s add the PHP buildpack to
our manifest.

➜ cf push
And it... starts?

➜ https://rehash.apps.pcfone.io/site/apptx.wtf/htdocs/about.pl
This looks like our Perl
code...not processing and
serving our webpage.

How do I customize the
conﬁguration of an
opinionated buildpack?

➜ options.json
Let’s take a look at the Cloud
Foundry Docs...

➜ what are those defaults?
We need to customize these
values.

➜ mkdir .bp-config
Let’s build a custom
conﬁguration.

➜ vim .bp-config/options.json
Let’s specify the version of
Apache httpd we use in our
production environment.

➜ cf push
It looks like we can’t download
and install httpd 2.2.29… it was
worth a try!

➜ more research
Back to the docs!
What else is available for us to
change?

➜ grab the defaults from the repo...
The PHP buildpack has an
opinionated conﬁguration. Let’s
start with taking a look at the
defaults.

➜ vim .bp-config/httpd/httpd.conf
What is the default Apache
httpd conﬁguration provided by
the buildpack?
Looks like the conﬁguration is
modularized...

➜ vim .bp-config/httpd/extra/httpd-modules.conf
Is mod_perl available to us
out-of-the-box?

➜ cf push
If we get rid of the
HTTPD_VERSION, we can push
with these default ﬁles and get
the same result as the
buildpack.

Let’s try enabling mod_perl and
see what happens

➜ cf push

➜ cf logs rehash
Looks like the modules are not
available to us.

How does this application
depend on its current
environment?

Where does mod_perl come from?
mod_perl is usually either
installed through the OS
package manager...
… or built from source
on that machine for that
machine.

➜ apt-cf-packager

➜ vim manifest.yml
We’ll make sure we’re targeting
our intended stack here...
...and set FLATTEN to false to
make sure we get all of the ﬁles
related to Perl and Apache.

➜ vim public/apt.yml
All we need are these two
packages to install mod_perl
and mod_apreq2
These are the names we’d use
with sudo apt-get
install

➜ cf push
Pushing it starts an app, and
going to this route in our
browser will let us download our
artifacts.

➜ download the packages
Time to download locally and
stick it into our app!

➜ let’s take a look at that download...
This directory contains our
mod_perl.so and
mod_apreq2.so for Apache to
load.
Here’s the supporting Perl 5.26
modules.

➜ cp -R lib lib-cflinuxfs3

Load our modules from an
absolute path from the pushed
directory.

➜ cf push

➜ cf logs rehash
Looks like the directory doesn’t
exist where we expected it to
be.

➜ cf ssh rehash

➜ ls ~

➜ ls app
This doesn’t look like the
directory we pushed...

➜ ls app/htdocs
This is what we would’ve
expected to be at
/home/vcap/app

➜ back to the php-buildpack docs!
Can we specify a diﬀerent path?

➜ vim .bp-config/options.json
Let’s specify the speciﬁc htdocs
directory for our site within our
codebase.

➜ cf push

➜ cf ssh rehash
Much better!

➜ lets check the perl-status

➜ cf logs rehash
Looks like we can’t ﬁnd Apache
modules that we need.

➜ vim startup.pl
Let’s create a startup script to
use libraries at speciﬁc paths.

Let’s conﬁgure our server to
load our startup script and
conﬁgure the additional
vendored module paths

➜ cf push
Wait...did that work?!

➜ open /perl-status
Now it’s time to run our
application.
We have a working Apache
server that can serve up Perl!

We can just include the app’s
configuration in our httpd.conf.
(Make sure to change any
hard-coded paths to use
$HOME or /home/vcap/app in
slash.conf and any included site
configuration files)

➜ cf push

➜ cf logs rehash
Now we’re missing
application-speciﬁc Perl
modules. We’re going to have
to go spelunking into the
production VM to ﬁgure out
where this lives.

Unfortunately, our app is also embedded in the environment!
This is where our application
lives (we think) so that’s what
we’re pushing

but it’s also over here!

and some over here!

(and probably some
in here!)

For now, maybe we can
use our vendoring trick
and just pull in the
application modules over
here into
lib-cflinuxfs3 ?

➜ cp site_perl lib-cflinuxfs3/perl5/
I wonder if this version mismatch
is going to bite us?

➜ cf push

➜ cf logs rehash
Yep! We can’t mix and match
perl modules between versions

Can I build my own
environment
and deploy it with the binary
buildpack?

Let’s move up a layer!
Instead of pushing this...

PHP
Buildpack

... we’ll push the
environment and the
installation.

Binary
Buildpack

Let’s push the previous directory
and our entire environment.
The Binary Buildpack requires
an explicit start command.

➜ cf push

➜ cf logs rehash-binary
Oh shoot! That path looks like
the absolutely path on our
production VM!

Maybe we can just replace all
with the expected structure?

➜ cf push

Wait...this looks a bit better.
Loading libperl.so is a new one...

Where the honk is libperl.so?
A quick search shows
us it’s tucked in over
here….
It’s in our pushed ﬁles,
so why isn’t our server
seeing it then?

➜ vim bin/startup.sh
Let’s move to a startup script to
have more control.

We’ll call our startup script
instead of the hard-coded
command

It looks like we’re using the
Apache and Perl in rehash-env.
...but we’re still seeing the same
problem loading libperl.so.

➜ yep, we Googled it
(And we got to read through
ﬁfteen year old forum posts)
It looks like we might have
trouble with the Apache built on
the production environment.

Can I rebuild my Application to
look like the ﬁnal deployment
structure?

The application doesn’t look
much diﬀerent, but cf push
shows a new error!
We’re missing a mysql shared
library.

Let’s update our manifest to
include the Apt Buildpack as
well as the Binary Buildpack.

➜ vim apt.yml

➜ cf push

We can’t connect to the
database on a local socket.
That’s how the prod VM worked,
so I think we’re in business!

How is this application conﬁgured
to talk to its external dependencies
(like a database)?

➜ vim Password.pm
This particular app builds a
custom Perl module that
embeds a “virtual user” holding
all of our configuration.
If you find this kind of
connection in code (or maybe
configuration that’s interpreted
by code), you can change it to
connect to your cloud services!

➜ cf create-service p.mysql db-small rehash-mysql

We’ll add our new service
instance to bind to our app

➜ cf env rehash (or via Apps Manager)
After pushing our app with the
updated manifest, we’ll get a set
of randomly generated
credentials.
We’ll grab them...

➜ vim Password.pm
… go back to our credential data
inside our application...

➜ vim Password.pm
… and we’ll just manually
hard-code this service binding’s
credentials for now.
We’ll want to pull from
VCAP_SERVICES eventually, but
this is the smallest possible test.

➜ cf push

Progress!
Now we’re failing because of
missing tables, which means
we’re connecting.

➜ one-time schema installation
The app sets up its schema with
a one-time administrative task.
We’ll run this targeting our new
database and...
...we fail because our MySQL
instance isn’t using the same
sql_mode as our production
environment.

➜ we have a few options...
Option 1: We can ﬁgure out
how to conﬁgure the service
instance to look more like our
production database.

Option 2: We can connect back
to our production database from
the cloud.

the cloud.
Option 3: We can create a new
database that looks more like
our production database.

the cloud.
Option 3: We can create a new
database that looks more like
our production database.
Option 4: We can refactor the
app to be able to use the
provided service instance.

➜ cf push
One more time...

➜ open https://v2.apptx.wtf
YES YES YES YES YES YES YES

When Should You Replatform?

TDA AppTx FY19Q1
App Modernization Journey
Easy Wins
Obvious
Rewrites
Big Business
Value
Non-trivial apps
not ready for
the cloud
Inherited
Heritage
Apps
You are here!
● Gain Operational Beneﬁts Leverage your platform tooling, such
as pipelines, and governance as you move to the cloud
● Maximize Your Return 5 days of replatforming work is much
much cheaper than committing to a full rewrite today
● Continue Your Journey Replatforming is a means to an end -
it’s the beginning of a modernization journey for many apps
● Gain Fast Insights You inherited an app that you don’t know
much about yet! Use replatforming as a quick start guide.
Back Oﬃce
Support

Thank You

Leveraging Standard Buildpacks to Migrate Not-So-Standard Apps

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Leveraging Standard Buildpacks to Migrate Not-So-Standard Apps

Similar to Leveraging Standard Buildpacks to Migrate Not-So-Standard Apps (20)

More from VMware Tanzu

More from VMware Tanzu (20)

Recently uploaded

Recently uploaded (20)

Leveraging Standard Buildpacks to Migrate Not-So-Standard Apps