DevOps portal¶
The DevOps portal is the self-service front end to the platform: you request VMs, databases, namespaces, apps, vaults and network rules there, and follow each request until it's applied. Almost everything it does is a merge request to a GitLab repo, so changes are reviewed, recorded and applied by CI.
URL: https://devops.pubinvest.co.uk
| Guide | For |
|---|---|
| Applications | Deploying a container image to Kubernetes |
| Hostnames and domains | The names your apps may use, internal and public |
| Virtual machines | Requesting a VM, SSH keys, connecting |
| Monitoring | The Grafana dashboards linked from each resource |
| Web firewall | Public sites, detect and block, exceptions |
Databases and secrets have their own sections: Databases, Secrets.
Signing in¶
Sign in with your Pub Invest account (Sign-in). You see the teams you're a member of and their resources.
Revealing a secret and approving a request need a fresh sign-in with your second factor, which lasts 15 minutes. The portal asks when it needs one.
Teams and roles¶
Your role in each team decides what you can do. Production is stricter than dev and qa.
| Non-prod | Prod | |
|---|---|---|
| See resources, dashboards and connection details | Viewer | Viewer |
| Request resources, vaults and network rules | Developer | Developer |
| Add and update secrets | Developer | Developer |
| Read app logs | Developer | Developer |
| Power actions (start, shut down, reboot), restart apps | Developer | Owner |
| Reveal and delete secrets | Developer | Owner |
| Publish sites and request web firewall exceptions | Developer | Developer |
| Switch a site between detect and block | Developer | Owner |
| Decommission resources | Developer | Owner |
| Approve requests, manage members, request quota | Owner | Owner |
Each role can do everything the roles below it can (owner > developer > viewer). The Teams page shows the same table and who is in each team.
How a change works¶
Every request becomes a numbered change (#123) and goes through the same steps:
- Preview. The form checks your request as you fill it in and shows what will happen: errors, notes, the approvals needed and, for repo changes, the file it will write. What the repo's CI would refuse is refused here first.
- Approvals.
- A team owner, unless you are one. An owner's own request in dev or qa usually needs no approval at all (the fast lane).
- Platform, for production, anything that crosses teams or reaches an external address, and anything that weakens the web firewall.
- Owners approve in the portal, never their own request. Platform approves the merge request in GitLab, or in the portal for VMs and access requests.
- Merge request. The portal opens it, waits for the pipeline and merges it once everyone has approved.
- Applied. CI or Flux applies it, and the portal waits until the result is live (the namespace exists, the app has rolled out, the database is created) before marking the change done.
A change waits up to 14 days for approval, then times out. You can withdraw your own request while it waits.
The portal checks GitLab for approvals, the merge and the pipeline with a backoff: every 15 seconds at first, slowing to about every 10 minutes for a change that has been waiting a long time. So a merge request approved hours after it was raised can take up to 10 minutes to move on.
The Changes page¶
Changes lists your teams' changes, newest first, each with its steps, approvers, merge request and result. The team chips narrow it to some of your teams.
Finished in limits the finished changes shown to the last 7 days (the default), 30 days,
90 days, 1 year or all time; the portal remembers your choice. Open changes are always listed,
whatever you pick. A link to a change (/changes/<id>) opens it even if it finished long ago.
When a change fails, its last step says why. Nothing is rolled back: what was merged stays merged, and putting it back is another change.