Giter VIP home page Giter VIP logo

bay's Introduction

SDP logo

Bay is the hosting and infrastructure layer for Single Digital Presence, delivered using amazee.io Lagoon.

Table of Contents

About

Bay is a fully managed platform and hosting environment that provides an open Platform as a Service model managed by SDP. It:

  • is an open-source hosting platform based on Lagoon.
  • allows agencies to build, test and deliver websites via the cloud.
  • is a Kubernetes-based (OpenShift) Docker container hosting platform with auto-scaling, auto-recovery and high-availability at core.
  • is based on open-source project Lagoon.

amazee.io Lagoon

Lagoon solves what developers are dreaming about: A system that allows developers to locally develop their code and their services with Docker and run the exact same system in production. The same Docker images, the same service configurations and the same code.

Use

Learn more from https://docs.lagoon.sh/

Bay Features

Lock-down Ingress with Pre-Shared Key

Using the nginx image, you can lock down access to your application with using a pre-shared key added at your CDN.

Set these environment variables in your nginx deployment:

  • BAY_INGRESS_HEADER defines the header which has the pre-shared key.
  • BAY_INGRESS_PSK is the token / PSK value.
  • BAY_INGRESS_ENABLED is a toggle for this feature, must be set to "true".

In your CDN configuration, set the header defined in BAY_INGRESS_HEADER with the token defined in BAY_INGRESS_PSK.

Once deployed, if the header is missing in the request nginx will return a 405 Not Allowed HTTP response.

Multiple architecture support

Bay images are available in both amd64 and arm64 architectures.

CI/CD

GitHub Actions is the platform used for CI/CD processes.

The process of building images is controlled in the GitHub Actions workflow (build-deploy-bay-images)[./.github/workflows/build-deploy.yml]

Images are built using Docker's buildx image builder in combination with the bake command and the corresponding bake file (gh-actions-bake.hcl)[./gh-actions-bake.hcl]

Breaking down the workflow

A matrix strategy is employed to concurrently build the images.

Note The matrix relies on the (repository variable)[https://docs.github.com/en/actions/learn-github-actions/variables#creating-configuration-variables-for-a-repository] IMAGES

Required variables

These variables are set as either GitHub Actions secrets or variables on the repository. IMAGES A JSON array object consisting of the names of the images to build. REGISTRY_TOKEN Required for container registry access. REGISTRY_USER Required for container registry access.

metadata-action

The workflow makes use of the (docker/metadata-action)[https://github.com/docker/metadata-action]. This Action takes the IMAGES variable as an input and creates the labels for the images.

This Action outputs a bake file inherited by the projects (bake file)[./gh-actions-bake.hcl] and provides the labels and tags used by the build process.

Vulnerability scanning

Published images are scanned using Trivy and any CVEs identified are reported in the repositories (Security Advisories)[https://github.com/dpc-sdp/bay/security/advisories].

Contribute

Open an issue on GitHub or submit a pull request with suggested changes.

Development builds

GitHub Actions is configured via the build-deploy workflow to build images for pull requests when they are opened and receive updates. These images are tagged with the PR number i.e. pr-86.

Support

Digital Engagement, Department of Premier and Cabinet, Victoria, Australia is a maintainer of this package.

License

This project is licensed under GPL2

Attribution

Single Digital Presence offers government agencies an open and flexible toolkit to build websites quickly and cost-effectively.

SDP logo

The Department of Premier and Cabinet partnered with Salsa Digital to deliver Single Digital Presence. As long-term supporters of open government approaches, they were integral to the establishment of SDP as an open source platform.

Salsa logo

bay's People

Contributors

amazeeio-deploy avatar anthony-malkoun avatar bomoko avatar dasrecht avatar desdrury avatar fleetadmiralbutter avatar fubarhouse avatar fubhy avatar growen avatar igayoso avatar jancorg avatar karlhorky avatar marji avatar markxtji avatar mdnadimhossain avatar mkeating avatar nicksantamaria avatar rocketeerbkw avatar rtprio avatar ryyppy avatar santhureturi308 avatar schnitzel avatar seanhamlin avatar skwashd avatar steveworley avatar stooit avatar thom8 avatar twardnw avatar vincent-gao avatar yusufhm avatar

Stargazers

 avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

bay's Issues

Trivy scans are failing because mailpit 5.x does not exist

Describe the bug
Mailhog has been superseded by Mailpit in 6.x but not backported to 5.x

The vars ingested by the scheduled scan is a matrix of images and branches which when compiled includes mailpit 5.x

To Reproduce
Steps to reproduce the behavior:

  1. Go to '...'
  2. Click on '....'
  3. Scroll down to '....'
  4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Tags are not set correctly

Describe the bug

When GitHub Actions executes the build-deploy workflow the container images should be tagged according to the expected behaviour

To Reproduce

Background (prerequisites)
Patched version of ACT
Clone this branch and run sudo make install then point the following commands and the resulting binary i.e. $HOME/go/src/github.com/nektos/act/dist/local/act

Testing workflow event files
Execute the build-deploy workflow

workflow-dispatch.yml

{
  "inputs": null,
  "ref": "5.x",
  "repo": "dpc-sdp/bay",
  "sender": "GROwen",
  "workflow": "test-context-values"
}
pull_request.json

{
  "pull_request": {
    "head": {
      "ref": "build/DDS-1723--sample"
    },
    "base": {
      "ref": "5.x"
    },
    "merged": false
  }
}

Steps to reproduce the behavior:

Execute the following commands adjusting the inputs based on the scenario

$HOME/go/src/github.com/nektos/act/dist/local/act workflow_dispatch -W .github/workflows/build-deploy.yml --defaultbranch "5.x" --actor "GROwen" -s GITHUB_TOKEN --var BRANCHES='["5.x"]' --var IMAGES='["ci-builder"]' --env REGISTRY=ghcr.io --container-architecture linux/amd64 --rm -P ubuntu-latest=catthehacker/ubuntu:act-latest -e .github/pull_request.json

You can also use the test-context-values.yml to check the GitHub context (ghc) that act computes for each run.

---
test-context-values.yml

name: test-context-values
run-name: Test cases for workflow triggers
on:
  pull_request:
    types:
      - closed
      - opened
      - synchronize
  schedule:
    - cron: '23 20 * * 0'
  workflow_dispatch:
jobs:
  github_context:
    runs-on: ubuntu-latest
    steps:
      - name: Dump GitHub context
        env:
          GITHUB_CONTEXT: ${{ toJson(github) }}
        run: echo "$GITHUB_CONTEXT"

Expected behavior

Scenarios

item workflow trigger Event Expected tag Notes
1 pull_request opened pr-86  
2 pull_request synchronize pr-86  
3 pull_request closed base branch GITHUB_REF i.e. 5.x Future state: delete pr tag
4 schedule   Default branch GITHUB_REF i.e. 5.x  
5 workflow_dispatch workflow_dispatch - request specifics - create-a-workflow-dispatch-event  GITHUB_REF i.e. 5.x

Additional context

Add any other context about the problem here.

Fix code scanning alert - 2390 et al

Find obsolete image manifests and remove from repo.

Some potential candidates for removal. Please go through github, review recent pulls etc.. to see if these can be ditched.

  • bay-buildx (not included in bake.hcl manifest)
  • bay-node-ripple
  • bay-node
  • bay-node-slim
  • bay-test

Elasticsearch version bump required

Fix code scanning alert

Tracking issue for:

Code scanning items are not attributed to the image tag they exist on

Describe the bug
When Trivy scheduled scans are executed they run on both the 5.x and 6.x branches however on the Code Scanning dashboard the associated CVEs are attributed to the branch that ran the workflow. For scheduled events that is whatever the default branch is set to.

To Reproduce
Execute the workflow vulnerability-scan-schedule-5.x.ym

In an attempt to achieve the desired behaviour I've created a reusable workflow in branch 'A' that is called from another branch, branch 'B'

Expected behavior
The code scanning advisories listing attributes the advisory to the ref/tag of the package or ref/tag of the actions/checkout step

Using the above example of branch 'A' and 'B' I would expect the advisories to be attributed to branch 'B'

A further example
i.e. from the workflow in the feature/specify-branch-on-scan-5.x branch

      - uses: actions/checkout@v4
        with:
          ref: 5.x

I would expect/desire that the advisories in code scanning are attributed to 5.x

Actual behaviour
The code scanning advisories listing attributes the advisory to the ref/tag of the branch that executed the workflow, in the below example 6.x

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.