Planet 4 is built on individual instances of a very common and powerful Content Management System (CMS): Wordpress. Here’s a snapshot of how the global architecture is designed:
The hosting of the P4 websites happens on Google Cloud Projects (GCP). Google Cloud Project was chosen for its ease of automation, and because we wanted our hosting to be based on 100% from Renewable Energy Sources (RES). For each environment, all three sites (develop, staging and production), the media assets and everything else, will be hosted on Google Cloud servers.
All our automatic implementation has been built on tools and processes offered by Google, but could be deployed in other solutions that support Helm/Kubernetes (with the necessary modifications).
All of our deployment code and scripts is in open repositories on Github.
All our sites are built and deployed using CircleCI (as our Continuous Integration server) and Docker images.
NROs with their own development teams are getting the necessary permissions to deploy new code in their online environments. This ways they can make modifications and extend functionality by developing their own plugins.
Once the Google Cloud Hosting is created, the GPI sysadmins / developers will create three sites and give NRO teams access to:
Before going live, and having a proper domain, this website looks like >>
A release (staging) site (
https://release.k8s.p4.greenpeace.org/<NRO>) should be always as close as possible to the production website.
As staging website for editors to be able to test an idea and do training.
As a release testing website: Right before we release a new version to production, the same code is deployed in this website, so that we can see if all goes well.
A development site (
https://k8s.p4.greenpeace.org/<NRO>) used for testing.
Used by developers to test and showcase new code before it is ready to be pushed to production. The various plugins/themes that we develop are pointing to dev-develop branches. Once a feature is merged to the dev-develop branch of a repository, it can be seen here. In the future, changes to the dev-develop branches of all predefined repositories will be triggering automatic builds of this website.
This website is not meant to substitute the local development environment for developers. Developers still need to have a local development environment where they will be doing development.
Modular container system (planet 4 code) based on Phusion’s docker-friendly Ubuntu base image.
Redis memory store caches application-generated full-page content, Wordpress object data, PHP session data and any ngx_pagespeed optimised assets. All elements can be enabled/disabled at container start by environment variables. Email delivery is via the Greenpeace GCP Sendgrid appliance, buffered via an Exim container (planet4 code).
Containers are intended to be a foundation for future projects, and are not purely Planet 4 specific. They are intended as common platforms from which to deploy infinite websites with identical infrastructure but differing content.
Base: Phusion base image
Modular, reusable base image designed to be a platform for all future services
Builds Openresty from source to include latest available OpenSSL v1.0.x and ngx_pagespeed
Delivers static content from /app/source/public
FastCGI cache backed by redis, on-demand purging, and delivery of stale data if the backend is down.
Generated on each push to planet4-base-fork
In use by the docker-compose development environment - https://github.com/greenpeace/planet4-docker-compose which is as near 1:1 dev-prod parity as possible before deploying development Minikube clusters locally.
Initiates a new NRO repository, Stateless buckets, CloudSQL databases and CircleCI project. Triggers initial deployments to develop and release environments.
Each NRO is a new repository, which is built from the NRO Generator repository template. it consists of three distinct environments: develop, release and master, each of which is a distinct set of resources and its own Helm deployment.
New container images are generated on each push to planet4-india
Tagged by build number, SHA and branch
Git semantic tags are considered production releases, eg v1.0.1
Tests are written in Bash Automated Testing System (BATS), a low-level test framework for checking bash operations and scripts.
On each commit the containers are built, tagged by commit SHA, branch and/or tag and run through unit/integration tests. Successful test suites on master branch are then tagged with
Helm package manager is the Kubernetes deployment tool of choice and recently became the native packaging solution.
Commits to NRO repositories trigger pipeline build/deploy workflows on CircleCI.
Develop / release branches are automatically deployed with Helm.
Tagged releases require manual intervention before being deployed to production.
The P4 Git Repo Dependency. Arrows indicate build hierarchy
Builds on upstream repositories trigger Circle CI workflows on each branch, with the following general format:
Container repositories perform builds
Unit and integration tests are performed
Containers are rolled out to the relevant Kubernetes environment via Helm**
Notifications are sent to RocketChat that a build is being held for manual approval
After manual approval, tagged container releases are deployed via Helm
After manual approval, new releases are initiated from develop branches via git flow release start, version pin / bump, git flow release, push
Tagged builds trigger new builds on downstream dependent repositories
Terragrunt is a thin wrapper around Terraform, which encourages DRY, modular code and automates remote state synchronisation.
The master branch of planet4-terraform-infra will be locked and require pull requests from develop. This will permit change reports from terragrunt plan to go through peer review before being implemented in CI.