Closed valiafetisov closed 1 year ago
I assume the staging environment will be deployed in our cluster? If yes i need to be able to setup secrets in github to access our chamber otherwise im not able to parse the dedicated AWS credentials safely to the runner.
Not sure if you have the needed access to set up secrets either @valiafetisov
I assume the staging environment will be deployed in our cluster?
I assume so too 🙂
to access our chamber
Please make sure that those keys doesn't have access to the complete chamber, but rather only to secrets needed by this concrete project.
Not sure if you have the needed access to set up secrets either @valiafetisov
No, I don't. I suppose only @wkampmann have. Or does @BracketJohn also have more rights than I do?
In any case, @DeusAvalon, I would ask you to a) specify what exact rights do you need for this repo (if you think they can be safely given to you) or b) to write a concrete step-by-step instruction on what exactly need to be set where. If b)
is required, maybe we can first setup CD on a fork of this repo to our org?
I assume so too
:D
Please make sure that those keys doesn't have access to the complete chamber, but rather only to secrets needed by this concrete project.
Yes ofc i would create a dedicated IAM role with only access to the specific SSM path for chamber :)
In any case, @DeusAvalon, I would ask you to a) specify what exact rights do you need for this repo (if you think they can be safely given to you) or b) to write a concrete step-by-step instruction on what exactly need to be set where. If b) is required, maybe we can first setup CD on a fork of this repo to our org?
According to the official docs i would need to become an admin
of the repository to create encrypted secrets.
And a repo fork into our own org would definitly be a simple solution to deploy the application without juggling permissions!
No, I don't. I suppose only @wkampmann have. Or does @BracketJohn also have more rights than I do?
sadly do not -> Wouter will need to create any github-side credentials. Can we find a workaround in the meantime + make sure that we ping him with a constructive & clear task-list once we have that?
If b) is required, maybe we can first setup CD on a fork of this repo to our org? And a repo fork into our own org would definitly be a simple solution to deploy the application without juggling permissions!
I agree with this proposition + think it even makes sense that we go this route through, so that in the end we have a very clear picture of what Wouter will need to do, to keep his required involvement to a minimum.
Ok, so let's start working on the fork and see if Wouter will grant @DeusAvalon admin
rights in the meantime or if we need to ask them to set secrets themselves
@valiafetisov can you prepare the fork and ping me when everything looks good? :) From this point on i will take over and add the deployment
Here is the fork. It's ready to be deployed unless you have some specific requirements
For Kubernetes to know if the pods are in a healthy state a healthcheck endpoint is required.
Usually the standard endpoint we are using is /api/healthz
but any other endpoint would be fine too for me.
(see t4f-gxmanager
or hos
projects for inspiration)
Please add one ASAP, in the meanwhile i will disable the healthcheck to allow kubernetes to start the containers.
The staging pipeline was implemented using Argo CD in a central (private) repo, therefore it's hasn't been automatically closed. The staging is currently available at https://powerhouse.switchboard.k8s.sidestream.tech
Goal
Working staging environment re-deployed on merge to main
Context
Since there is something sensible to display now (after merging #29) we would want to deploy this project. Note, that currently it will have 3 services: api, frontend and the database. Have a look at the
docker-compose.yaml
file as well asnginx.conf
for inspiration. Although currently the database is set to be sqlite, in production it will always be postgresql. Note, in this project we're currently using prisma (but that might change in the future).One additional complexity here is that this repo is not owned by our github organisation. We anyway have access to github actions which are already enabled and utilised.
Tasks
JWT_SECRET
contains a long password-like string/
/api
{ coreUnits { id } }
should return no errors