George Wilson presented on modern cloud architecture and automation for websites built with content management systems like Joomla. He demonstrated how to automate the deployment of a Joomla site on AWS using just 7 commands and a configuration file. This included uploading the code, creating the application version, and provisioning the environment. Wilson discussed the rise of using CLIs and APIs to manage websites and their content programmatically. Documenting APIs with OpenAPI/Swagger was presented as a best practice. While these techniques may not apply to all Joomla sites, Wilson argued they are relevant for many sites in Joomla's target markets that prioritize agility and automation.

1. George Wilson - December 2020
Building Modern Websites
The Cloud, APIs and CLIs

2. • Senior Consulting Engineer @
Automation Logic
• Working in DevOps on Government
Projects
• Joomla Leadership 2013-2019
• Joomla 4 Release Lead
• Please feel free to reach out on:
• Glip: George Wilson
• Email:
george.wilson@community.joomla.org
• GitHub: wilsonge
About Me

3. • Many people reference Google
trends as a measure of Joomla’s
decline
• No one mentions Wordpress in
the UK is down ~50% in Google
trends over the last 5 years
• Partly because their GLOBAL
marketshare remains constant
• Why have many companies
and agencies have fallen out
of love with the traditional PHP
CMS’?
Where did this talk come from?

4. The Cloud

5. • Ultimately any group of servers containing
applications and databases is a cloud
• Traditional PHP Shared hosting by <insert
you hosting provider here> is a cloud
• But these days the cloud o
ff
ers so many
more services than just a hosting platform
• Machine learning
• Secrets Management
• Storage
• CDN
• Container Management
• Virtual Machines
So what is the cloud?

6. Why are People Using the Cloud
• Depth of services
• Costs/Scalability - Pay for what you use and scale it as required
• Flexibility
• Reduced Downtime
• Great disaster recovery options
• Excellent Monitoring Capabilities
• Serverless

7. • These days people are tending towards
one of the 3 platforms:
1. AWS
✦ General Purpose, often small
business
2. Azure
✦ Often more corporate based as
more transparent on it’s security
model
3. GCP
✦ Highly data focussed - many
optimisations for large data sets &
analytics
The Modern Cloud
Source: https://start.jcolemorrison.com/understanding-modern-
cloud-architecture-on-aws-a-concepts-series/

8. • Amazon’s Off ering
• Dozens of services baked in -
but generally speaking a PHP
Environment might look like:
• VPC (Network)
• S3 (Storage)
• EC2 (Linux VM)
• RDS (MySQL)
• Route 53 (DNS)
AWS

9. For when that sounds like too much
Elastic Beanstalk

10. For when that sounds like too much
Elastic Beanstalk
15 minutes later…

11. For when that sounds like too much
Elastic Beanstalk
Around $19 a month including a HA Database

12. Caveat
This just helps you to get a working setup in AWS this isn’t for
use in real life!!

13. • People no longer use static
con
fi
gurationfi les
• Lack of portability between
environments
• Desire to automate creation of
environments in ever simpler ways
• .env project
• Pulls in from environment
variables OR from
fi
les
• Used in most modern PHP
projects notably Laravel
• Would allow full use of Joomla in a
Beanstalk project
Modern Configuration Files

14. Quick Format Comparison
Joomla - Global
fi
le containing prod values. Values assembled from con
fi
g object as required
Laravel - .env
fi
le containing dev values, then assembled into con
fi
guration
fi
les
which in turn are loaded into a Con
fi
guration class

15. Things we can do
in core about this
https://github.com/joomla/joomla-cms/
compare/4.0-dev...wilsonge:feature/dotenv?
expand=1

16. Managing Installation/Updates
• So in summary:
• We have a Linux machine which gets destroyed and rebuilt every time we make a
new deployment from our ZIP
fi
le
• Questions Remaining:
• How do we disable use of Global Con
fi
g in the UI - these values are no longer
con
fi
gured through Joomla, but by our environment variables
• Same sort of switch required for loading our .env
fi
le for local development
• How do we manage the installation process (given all the normal form
fi
elds are
useless) - but we still need to setup our SQL DB?
• How do we manage Joomla upgrades - committing the physical
fi
les to git is
annoying

17. Automating Things
• My job is to automate the creation of resources
• In the words of a former team lead “You really hate GUI’s don’t you?”
• We’re going to use two tools for this
• AWS CLI (v2) - Installation Instructions: https://docs.aws.amazon.com/cli/latest/
userguide/install-cliv2.html
• I have authenticated to my personal AWS Account already
• JQ - JSON Parsing for Bash - https://stedolan.github.io/jq/download/
• We’re largely going to follow the tutorial documented here https://
docs.aws.amazon.com/elasticbeanstalk/latest/dg/environments-create-awscli.html
but being a bit more speci
fi
c to deploying my dummy Joomla instance

18. Automating Things
• aws elasticbeanstalk create-storage-location
• aws elasticbeanstalk create-application --application-name george-joomla-cli
• aws ec2 import-key-pair --key-name "george-primary-laptop-ssh" --public-key-
material
fi
leb://~/.ssh/id_rsa.pub
Ensure that a storage location has been setup
Create the main application (empty at this point) in Elastic Beanstalk
Setup my public ssh key into AWS for use later

19. Automating Things
• aws s3 cp build/tmp/packages/Joomla_4.0.0-beta6-dev-Development-
Full_Package.zip s3://elasticbeanstalk-eu-west-2-846108235618/test/
Joomla_4.0.0-beta6-dev-Development-Full_Package.zip
• aws elasticbeanstalk create-application-version --application-name george-
joomla-cli --version-label v1 --source-bundle S3Bucket=elasticbeanstalk-eu-
west-2-846108235618,S3Key=test/Joomla_4.0.0-beta6-dev-Development-
Full_Package.zip
Name of storage location from previous step
Path we want to drop
our data in - can be anything
we just need to remember it for
the next step!
Copy our zip that we want to deploy into the above storage location
Now upload our local copy of Joomla upstream

20. Automating Things
• aws elasticbeanstalk list-platform-versions --
fi
lters
'Type="PlatformName",Operator="contains",Values="PHP"' | grep
PlatformArn | awk -F '"' '{print $4}' | awk -F '/' '{print $2}'
• aws elasticbeanstalk create-confi guration-template --application-name
george-joomla-cli --template-name v1 --solution-stack-name "64bit Amazon
Linux 2 v3.1.3 running PHP 7.4"
Check what PHP Versions are available for us to use - Source: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/launch-now-url.html#launch-now-url.params

21. Automating Things
• aws elasticbeanstalk create-environment --cname-pre
fi
x george-joomla-cli --
application-name george-joomla-cli --template-name v1 --version-label v1 --
environment-name v1-initial --option-settings
fi
le://options.json
Create the environment - start with a simple
con
fi
guration!
Setup networking (not required in some cases)
Required permissions for EBS to connect to our Linux Box
Ensure our Linux Box gets a public IP address so we can access
it through the browser
Ensure our SSH key can access the Linux Box

22. Automating Things
How to
fi
nd out what the magic options are?
• Google -> AWS Documentation :)
• https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-
options-general.html

23. Settings in your Github Repo!
• Not all options have to be con
fi
gured
in this JSON
fi
le!
• Some options can be controlled in
your GitHub repo
• Environment speci
fi
c things will
need to be on the command line still
• MySQL Database: Environment
JSON File
• Joomla Site Name: con
fi
g
fi
le in
repo
Automating Things
Source: https://github.com/aws-samples/eb-php-wordpress

24. Summary
• We setup a fully automated
Joomla environment with just 7
commands (and 1 json con
fi
g
fi
le)
• This means we can spin up our
environment in a public location
again and again (and delete it on
repeat) at will
• We also have good visibility over
the environment (in a way we
wouldn’t have on a traditional
PHP host)
Automating Things

25. Cli Control
Source: https://imgur.com/4xThP

26. … and why should you try it?
• Many people have been getting back into
CLIs
• Development with git
• Containers with docker
• Companies are making automation a
priority!
• Safety is running the same command
multiple times and always getting the
same result
• Works great as a compliment to rest APIs
Why is CLI back in Fashion?

27. • Runs outside the server (e.g.
AWS Cli)
• Allows users to manage their
data in your site (Create an
event on your events site,
editing pricing of their product
in your shop etc.)
• Generally uses a Sites API to
exchange data and will require
authentication
Client Side
Client Side vs Server Side CLI
• Runs on the server (e.g. WP-CLI,
Joomla 4 Cli)
• For managing the server (e.g.
Backups, Updates etc.)
• As it sits on the server will not
require authentication as access to
the server is the authentication
• Even can be used (e.g. Laravel
Artisan) to help you do development
work
Server Side

28. CMS Relevance?
WP CLI tool (with code
contributed by Automattic)
has over 4.3k stars on
Github - that’s more stars
than Joomla’s main
repository (3.6k)!

29. • Joomla 4 has rebuilt it’s CLI layer
(based on the Symfony library)
• Already has buy-in (and
excitement) from several major
extension providers
• Allows the automation of basic
functionality for day to day
maintenance
• Of course there’s still the
standard backend for content
creators and people who
aren’t con
fi
dent with the CLI!
Joomla 4 Server-Side CLI

30. • Most site builders have a basic
setup and set of extensions they
precon
fi
gure onto the majority of
their websites
• Imagine doing this in a single
script!
Joomla 4 Server-Side CLI

31. APIs and Client Side CLIs

32. Are APIs relevant to a CMS?
• Yes! Many people already use them:
• e.g. Backing ups to AWS (e.g. Akeeba)
• Integrations (e.g. MailChimp)
• Google Analytics
• Payment Providers
• If you’re building a website where customers can do a level of administration (e.g.
shops where people can add their products etc. there will be demand for this!)
• There’s demand for being able to programatically con
fi
gure your website in
di
ff
erent environments!

33. What are the characteristics of a modern HTTP API?
• Language - Consistent response formats (options include JSON+LD, JSON API
etc.)
• Ability to Filter/Search for data (including sort order)
• Pagination
• Authorisation and Authentication (often OAuth)
• Good documentation (even if it’s an internal API)
• Responses to the 4 main HTTP Methods - POST and GET (like on a normal
website) as well as PUT/PATCH and DELETE
• REST is generally considered the go to these days (sometimes GraphQL for
highly nested data)

34. • Built to allow interactions with
Joomla with other mediums (e.g.
mobile to Joomla, other websites
with Joomla)
• Extendable to allow adding
custom endpoints (and therefore
users to be able to authenticate
into Joomla)
• Extendable authentication
allowing you to optimise based
on what you want to use the API
for
Joomla 4 API

35. • Open API is a method for
documenting APIs in JSON or
YAML
• Originally called swagger
before being moved to a
community managed project
• https://github.com/OAI/
OpenAPI-Speci
fi
cation
Documenting a custom API with
Open API

36. Documentation
• Various auto-documentation
sources exist for OpenAPI
fi
les
• Redoc is one of my personal
favourites
• https://github.com/Redocly/
redoc
• Simple custom element and
CSS means it is super
customisable
The Art of the Possible

37. Documentation
• Swagger Docs is also well
known
• Also used for our own Joomla
Downloads Site API
• Nice tool at editor.swagger.io
that allows you to see your
JSON File and the rendered docs
page on the same screen
The Art of the Possible

38. Demo Time
Going through editor.swagger.io

39. Advanced - SDK Generation
• All azure’s integrations with other
languages (NodeJS, PHP, Java etc)
start with an Open API File
• Then each language’s SDK is
generated
• Guarantees parity between libraries
(relevant if you have lots of API
endpoints)
• This could be useful for easy 3rd party
integrations with shops or event sites
• https://github.com/Azure/autorest
The Art of the Possible

40. • Authentication and Requests
made through the API
• CLI gives users more options
and situationally can be easier
to create automated
approaches
• API Auth token stored locally on
your computer to
fi
lesystem (e.g.
~/.aws/credentials etc).
• https://clig.dev/
Client Side CLI
https://www.contentful.com/developers/docs/tutorials/cli/
extension-management/

41. Summary
• The modern web is based around the ability to deploy quick and fast updates
(as languages evolve)
• Why? In my opinion this is due to both the increased Agile nature of
projects (especially in many digital agencies) as well as the faster paced
growth of the PHP Language/The Cloud (and frameworks taking
advantages of these new features)
• This is highly driven in many medium and large sized companies by increased
use of the CLI and API
• Increased automation has built up around this - in order to reduce the impact
of human error as they work quickly

42. Summary
• Many digital agencies have moved into the cloud to take advantage of the
managed o
ff
erings by cloud providers
• Still gains the ability to control your data (unlike Wix/Squarespace) but with
many more o
ff
erings than those given by traditional PHP Hosts
• More
fl
exibility for sites that may need a more niche service as well as
better log management
• Cost di
ff
erences do exist - but in the grand scheme of anything other than
individual sites or extremely small startups are negligible

43. Summary
• We looked at the services involved in deploying Joomla into one cloud
provider (AWS)
• We looked at the small changes that would make Joomla more in tune with
the larger PHP ecosystem and would make deploying Joomla more simple
when deploying into the cloud
• And the further work that would be required to make this realistic for
hosting Joomla services
• We looked at automating the setup of a Joomla site in a 0 to hero setup with
just 7 commands (and 1 con
fi
g
fi
le)

44. Summary
• We looked at the rise of the CLI
• We di
ff
erentiated them into server side and client side o
ff
erings and what the
di
ff
erence between them was
• We saw the already existing demand for this as a service in the CMS Marketplace
in the Wordpress CLI
• We looked into what to expect from an API
• We looked at use cases, how to document them and expose them to the clients
on your site through Open API and Swagger
• Finally are these concepts relevant to many Joomla Sites?
• Absolutely not - but they are relevant to lots of sites that fall into Joomla’s target
market too!

45. Questions?
Thank you for watching!