The Giant Swarm web user interface. It lets users:
- View and manage clusters
- Manage their account
- Add / remove organizations
- Add / remove members from organizations
- Learn how to get started with their kubernetes clusters by following a guide
Happa is intended to be deployed to Giant Swarm control planes and acts as a client to the Giant Swarm API.
Getting started with development / demoing
Happa has to talk to an API endpoint. It used to be possible to change a locally running happa's configuration to talk to any API server. This has since been restricted with CORS accept headers.
The only option now is to bring up the API suite locally, or demo happa running on one of our installations.
Bring up the API suite locally
This requires Docker and
docker-compose, and access to our private
Currently only Giant Swarm employees are able to see that repo. We're considering
open sourcing it.
api and dependencies first by going to the
api repo and running
the dockercompose file in the testing folder there:
cd $GOPATH/src/github.com/giantswarm/api/testing make aws make up
make awscommand in that example? There is also
make kvmto create a docker-compose file that sets up the API and other microservices as if they were on these types of installations.
As part of
./fixtures.sh will run and create the initial user and
organization you can log in with.
You should now be able to start happa's development server from within this (giantswarm/happa) repo like so:
docker-compose up --build
It can take a minute or two for dependencies to be available.
Wait for a line like
: Compiled successfully. to appear in the console.
This shows that the dev server is ready to handle requests.
Then visit http://localhost:7000/
Any code changes should cause the browser to reload automatically.
Once everything is up you can log in as
password as your password.
If you want to test out things like the forgot password feature, all e-mail ends up in the mailcatcher app running at http://localhost:1080/
Tear down the dev / demo environment
Ctrl-C to escape from
docker-compose log output.
docker-compose stop to stop containers or
docker-compose down to remove them.
We have a few tests, and are adding more. Run them with
Commits to the master branch are continuously deployed to Giant Swarm test installations. Tagged releases are continuously deployed to all installations.
Building / Running locally
If you want to test locally
make production will build and run
Happa's production container.
Happa makes use of the development container to produce production assets. The production container then takes those assets and serves them using nginx.
The build process is as follows:
Build the development container
Create production assets using the development container (
grunt build), save them in the dist folder.
Create the production container
Use environment variables to adjust the behavior of this application in production.
|API_ENDPOINT||URL to Giant Swarm's API.||http://docker.dev:9000|
|PASSAGE_ENDPOINT||URL to Passage, which helps users when they lose their password or have been invited to create an account.||http://docker.dev:5001|
|INGRESS_BASE_DOMAIN||The ingress base domain of the installation that Happa is on. This affects the getting started guide.||k8s.sample.io|
|AWS_CAPABILITIES_JSON||A JSON array representing all the details of AWS instance types. This has been extracted so that we have a single point of truth for this information|
|AZURE_CAPABILITIES_JSON||A JSON array representing all the details of Azure vm sizes. This has been extracted so that we have a single point of truth for this information|
|ENVIRONMENT||A string that indicates where Happa is running.||development|
These environment variables affect the config object in
A startup script (
start.sh) applies the values from the environment variables
index.html by editing the file. This way Happa remains a fully static website
that can be served by nginx.
In development, environment variables are not applied. This is because the development container does not start in the same way that the production container does.
Redux in a nutshell
╔═════════╗ ╔══════════╗ ╔═══════════╗ ╔═════════════════╗ ║ Actions ║──────>║ Reducers ║──────>║ Store ║──────>║ View Components ║ ╚═════════╝ ╚══════════╝ ╚═══════════╝ ╚═════════════════╝ ^ │ └───────────────────────────────────────────────────────────┘
Components should only emit actions.
Reducers listen for actions and emit a new state.
The view listens for changes to the state and renders.
By following these guidelines we should get some benefits in keeping component logic focused on rendering, and not on doing the actual work of manipulating state.
Happa uses a custom icon pack which we can manage at https://fortawesome.com
Login details are in keypass, search for 'fortawesome'.
<script src="https://use.fonticons.com/d940f7eb.js"></script> line in
index.html is what includes the file for us.
More information about our font kit and how to use it can be found here: https://fortawesome.com/kits/d940f7eb/docs
Checking for outdated dependencies
To see what dependencies have updates run
Happa's Code Style is determined by
prettier. Please make sure files in the
src directory have passed through
prettier before committing them to the repo.
A CI step will enforce that this has happened, failing the CI if it detects that
prettier would make any changes.
You can run
prettier on the whole codebase using
yarn run prettier.
We use the following config params:
Pre commit hooks
To avoid pushing code that will fail the CI due to codestyle issues, you can add the following as a pre-commit hook.
#!/bin/bash git diff --name-only --cached | grep "\.js$" if [ $? -eq 0 ]; then make validate-prettier fi
To add a pre-commit hook, save the above as a file called
pre-commit in the
Make sure it has has
0755 as the permission.
Publishing a Release