GithubHelp home page GithubHelp logo

nais / deploy Goto Github PK

View Code? Open in Web Editor NEW
0.0 12.0 6.0 3.18 MB

NAIS deploy: multi-cluster Kubernetes deployments

Home Page: https://doc.nais.io/deployment

License: MIT License

Dockerfile 0.09% Makefile 1.99% Go 95.44% Ruby 0.27% Shell 0.94% JavaScript 0.33% Smarty 0.95%
kubernetes nais-features

deploy's Introduction

NAIS deployment

Overview

NAIS deploy facilitates application deployment into NAV's Kubernetes clusters.

Developers push or merge code into the master branch of a Git repository, triggering an automated build using (preferably) Github actions. A successful build produces a Docker image artifact, which is uploaded onto Github package registry. The final step in the build pipeline sends an API request to NAIS deploy to deploy the Docker image onto one of our Kubernetes clusters.

Sequence diagram of deployment components

How it works

  1. The teams pipeline use deploy to send a deployment request to hookd.
  2. hookd receives the deployment request, verifies its integrity and authenticity, and passes the message on to deployd via gRPC.
  3. deployd receives the message from hookd, assumes the identity of the deploying team, and applies your Kubernetes resources into the specified cluster.
  4. If the Kubernetes resources contained any Application or Deployment resources, deployd will wait until these are rolled out successfully, or a timeout occurs.

Any fatal error will short-circuit the process with a error or failure status posted back to Github. A successful deployment will result in a success status. Intermediary statuses will be posted, indicating the current state of the deployment.

Usage

The usage documentation has been moved to NAIS platform documentation.

Deploy API

We strongly recommend that teams use the deploy cli to deploy, rather than posting directly to hookd.

Post to /api/v1/deploy to deploy one or more resources into one of our Kubernetes clusters.

Successful requests result in creation of a deployment object on GitHub. Use this object to track the status of your deployment.

Request specification

{
  "resources": [
    {
      "kind": "Application",
      "apiVersion": "nais.io/v1alpha1",
      "metadata": { ... },
      "spec": { ... },
    }
  ],
  "team": "nobody",
  "cluster": "local",
  "environment": "dev-fss:default",
  "owner": "navikt",
  "repository": "deployment",
  "ref": "master",
  "timestamp": 1572942789,
}
Field Type Description
resources list[object] Array of Kubernetes resources
team string Team tag
cluster string Kubernetes cluster, see NAIS clusters
environment string GitHub environment
owner string GitHub repository owner
repository string GitHub repository name
ref string GitHub commit hash or tag
timestamp int64 Current Unix timestamp

Additionally, the header X-NAIS-Signature must contain a keyed-hash message authentication code (HMAC). The code can be derived by hashing the request body using the SHA256 algorithm together with your team's NAIS Deploy API key.

Response specification

{
  "logURL": "http://localhost:8080/logs?delivery_id=9a0d1702-e7c5-448f-8a90-1e5ee29a043b&ts=1572437924",
  "correlationID": "9a0d1702-e7c5-448f-8a90-1e5ee29a043b",
  "message": "successful deployment",
  "githubDeployment": { ... }
}
Field Type Description
logURL string Direct link to human readable frontend where logs for this specific deployment can be read
correlationID string UUID used for correlation tracking across systems, especially in logs
message string Human readable indication of API result
githubDeployment object Data returned from GitHub Deployments API

Response status codes

Code Retriable Description
201 N/A The request was valid and will be deployed. Track the status of your deployment using the GitHub Deployments API.
400 NO The request contains errors and cannot be processed. Check the message field for details.
403 MAYBE Authentication failed. Check that you're supplying the correct team; that the team is present on GitHub and has admin access to your repository; that you're using the correct API key; and properly HMAC signing the request.
404 NO Wrong URL.
5xx YES NAIS deploy is having problems and is currently being fixed. Retry later.

Application components

hookd

This service communicates with Github, and acts as a relay between the Internet and our Kubernetes clusters.

Its main tasks are to:

  • validate deployment events
  • relay deployment requests to deployd using gRPC
  • report deployment status back to GitHub

The validation part is done by checking if the signature attached to the deployment event is valid, and by checking the format of the deployment. Refer to the GitHub documentation as to how webhooks are secured.

deployd

Deployd's responsibility is to deploy resources into a Kubernetes cluster, and report state changes back to hookd using gRPC.

gRPC

gRPC is used as a communication protocol between hookd and deployd. Hookd starts a gRPC server with a deployment stream and a status service. Deployd registers as a client on Hookd. When Hookd receives a deployment request, it adds it to the relevant gRPC deployment stream. Deployd acts on the information, and then sends a deployment status to the gRPC status service on Hookd. Hookd publishes the deployment status to Github.

Compiling

Install Golang 1.15 or newer.

Check out the repository and run make. Dependencies will download automatically, and you should have three binary files at bin/hookd, bin/deployd, bin/deploy and bin/provision.

To run the integration tests, please download and use a Kubernetes test environment:

# change into the home directory before running `go install`
cd
go install sigs.k8s.io/controller-runtime/tools/setup-envtest@latest
# note: for Apple Silicon, add: `--os darwin --arch amd64`
source <(setup-envtest use -p env)

Running locally

For a combination of more tools running locally (hookd, Console frontend and more), check out the nais/features-dev repo.

Postgres

Start the database by running docker-compose up. This will start an empty local database. When you start hookd, the schema will be patched to current version. If this is the first time running this database, you have to add a dummy deployment key for deploy to work. In this case, the deployment key is 20cefcd6bd0e8b8860c4ea90e75d7123019ed7866c61bd09e23821948878a11d.

psql -U postgres -h localhost -p 5432 hookd <<< EOF
insert into
    apikey (key, team, created, expires)
    values ('1608bf2caf81bb68d50bfb094a8e0d90de2b27260767a64a0103c6255077eb446f4fabcb7ae94514380b4fdc006bd50dfe2ea73f4b60c0c55891a60f',
            'aura', now(),now()+interval '10 years');
EOF

Hookd

run ./bin/hookd For local development, hookd will by default start with an insecure listener and github integration disabled. secure listener can be turned on passing the following flags:

--grpc-authentication                Validate tokens on gRPC connection.

Github integration can be turned on using the following flags:

--github-app-id int                  Github App ID.
--github-client-id string            Client ID of the Github App.
--github-client-secret string        Client secret of the GitHub App.
--github-enabled                     Enable connections to Github.
--github-install-id int              Github App installation ID.
--github-key-file string             Path to PEM key owned by Github App. (default "private-key.pem")

Deployd

To enable secure listener in deployd, the following flags apply:

--grpc-authentication           Use token authentication on gRPC connection.
--grpc-use-tls                  Use secure connection when connecting to gRPC server.

Deploy

Once the above components are running and configured, you can deploy using the following command:

./bin/deploy \
    --resource resource.yaml \
    --cluster local \
    --apikey 20cefcd6bd0e8b8860c4ea90e75d7123019ed7866c61bd09e23821948878a11d \
    --deploy-server localhost:9090 \
    --grpc-authentication=false \
    --grpc-use-tls=false \
    --wait \
;
./bin/deploy --resource res.yaml --cluster local --apikey 20cefcd6bd0e8b8860c4ea90e75d7123019ed7866c61bd09e23821948878a11d --deploy-server http://localhost:8080 --wait

Verifying the deploy images and their contents

The images are signed "keylessly" (is that a word?) using Sigstore cosign. To verify their authenticity run

cosign verify \
--certificate-identity "https://github.com/nais/deploy/.github/workflows/release.yml@refs/heads/master" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
europe-north1-docker.pkg.dev/nais-io/nais/images/deploy@sha256:<shasum>

The images are also attested with SBOMs in the CycloneDX format. You can verify these by running

cosign verify-attestation --type cyclonedx  \
--certificate-identity "https://github.com/nais/deploy/.github/workflows/release.yml@refs/heads/master" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
europe-north1-docker.pkg.dev/nais-io/nais/images/deploy@sha256:<shasum>

deploy's People

Contributors

ahusby avatar christeredvartsen avatar dependabot[bot] avatar frodesundby avatar gtcno avatar jhrv avatar jksolbakken avatar kimtore avatar kyrremann avatar mortenlj avatar rbjornstad avatar sechmann avatar starefossen avatar thokra-nav avatar toresbe avatar tronghn avatar x10an14 avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

deploy's Issues

Helper application to create deployment requests from pipelines

This application should:

  • constrain clusters to well-known values (dev|prod + fss|sbs)
  • post a well-formed deployment request with one or more Kubernetes resources as payload
  • fail if the deployment request wasn't created successfully
  • optionally, block until the deployment has concluded with failure, error, or success

GitHub deployment status set to inactive if using GHA job environment

If we define an environment within a GHA job (https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment)

jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: deploy
        ...

a deployment is created on GitHub with said environment.

If we use the deploy action as a step within this job, a second deployment by the action is created.

If both of these deployments use the same environment, whichever deployment that has its state set to success last will cause

all prior non-transient, non-production environment deployments in the same repository with the same environment name [to] become inactive (source)

As the job itself finishes after the deploy action, it ends up looking like this:

Screenshot showing two GitHub deployments referencing the same commit and environment where the nais/deploy deployment is set to inactive

Not sure how we should fix this. Perhaps attempt to look for an existing deployment and update it instead of creating a new one?

Feature request: støtte flere dokumenter i nais.yaml

Ble litt overrasket over at det ikke fungerte å putte to resource-er i samme dokument og deploye de med nais/deploy/actions/deploy@v1. Siden det funker når man bruker kubectl apply -f nais.yaml, så tenkte jeg naivt at det kom til å funke med github-actionen deres.

Use-case er når man har tett koplede pods som skal deployes sammen. I mitt tilfelle bitnami/redis:5.0.10 og oliver006/redis_exporter:1.15.1.

Eksempel

Gitt at nais.yaml inneholder:

apiVersion: "nais.io/v1alpha1"
kind: "Application"
metadata:
  name: testapp1
  namespace: arbeidsgiver
  labels:
    team: arbeidsgiver
spec:
  image: navikt/nais-testapp:65.0.0

---
apiVersion: "nais.io/v1alpha1"
kind: "Application"
metadata:
  name: testapp2
  namespace: arbeidsgiver
  labels:
    team: arbeidsgiver
spec:
  image: navikt/nais-testapp:65.0.0

så ønsker jeg at

kubectl apply -f nais.yaml

og github actionen

jobs:
  deploy:
    name: Deploy 
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: nais/deploy/actions/deploy@v1
        env:
          APIKEY: ${{ secrets.NAIS_DEPLOY_APIKEY }}
          CLUSTER: labs-gcp
          RESOURCE: nais.yaml

er ekvivalente.

Slik det er nå, så vil kubectl opprette begge nais-application-ene, mens github actionen kun en av dem.

(Edit: ser at man kommer nærme ved å liste opp flere filer i RESOURCE-parameteret, men hadde vært fint om kubectl og actionen støttet det samme.)

Robust handling of deployment statuses

Mark Kafka messages as consumed only when Github says that the deployment status was successfully created. Additionally, consider retries when producing these messages on the Kafka topic.

broken link

README.md has broken link.

https://doc.nais.io/deployment should be used and points to the whole section of deployment...

Mulighet for krypterte Kubernetes payload

Med dagens løsning vil Kubernetes payloadene lagres i klartekst i github APIet, for open-source prosjekter betyr dette at URL-er blir liggende tilgjengelig for scraping. Selv om disse ikke er sett på som Temmelig Hemmelig kan det være litt uheldig at de er så lett tilgjengelig da det beskriver noe av vår infrastruktur som ikke trenger å være offentlig informasjon.

Løsningen som har blitt diskutert er å ta i bruk JWE for å kryptere payloadet og eksponere et JWKS endepunkt som kan brukes av deployment-cli, dette gjør at det ikke blir noe mer kompleksitet for de som bruker deployment-cli.

En annen fremtidig mulighet med dette patternet er at vi kan kryptere secrets og opprette Kubernetes secrets via samme pipeline.

Action loggen viser flere poder enn de som blir deployet

Når man ser på loggen for en deployment så får man også med poder som ikke er en del av nåværende deployment. Det kan være ganske forvirrende.

[2022-11-06T23:40:56.787409667Z] Status: in_progress: Pod/vaktor-plan-7f9874dc75-zflvg (Unhealthy): Readiness probe failed: Get "http://10.7.81.29:4191/ready": dial tcp 10.7.81.29:4191: connect: connection refused
[2022-11-06T23:40:57.549581428Z] Status: in_progress: Pod/vaktor-plan-757cb4d4f9-cghjv (Pulling): Pulling image "ghcr.io/navikt/vaktor-plan-backend/vaktor-plan-api:b6276559abc095d2668f089be55a19c7cdd9f83d"

Her var det en deployment som feilet, og når man deployet en ny versjon så fikk man pods fra den gamle deploymenten i loggen. Her burde vi ta høyde for replicaset i stedet.

Github Action: https://github.com/navikt/vaktor-plan-backend/actions/runs/3406487347/jobs/5665220726

Deployd feiler hvis namespace er definert i en alerts

Hvis man har med namespace i metadataen til en alerts-ressurs så feiler deployd med

Published deployment status to GitHub: Deployment failed: resource X: the server could not find the requested resource

Dette fungerer når man bruker kubectl apply direkte, som gjør det litt vanskelig å feilsøke problemet.

Payloads

{
    "ref": "master",
    "description": "Kyrre tester curl-deploy",
    "environment": "dev-fss",
    "payload": {
        "version": [1, 0, 0],
        "team": "aura",
        "kubernetes": {
            "resources": [
            {"apiVersion":"nais.io/v1alpha1","kind":"Alert","metadata":{"name":"spsak-alerts","namespace":"default","labels":{"team":"aura"}},"spec":{"receivers":{"slack":{"channel":"#sp-sak"}},"alerts":[{"action":"`kubeclt describe pod {{ $labels.kubernetes_pod_name }} -n {{ $labels.kubernetes_namespace }}` for events, og `kubectl logs {{ $labels.kubernetes_pod_name }} -n {{ $labels.kubernetes_namespace }}` for logger","alert":"applikasjon nede","description":"{{ $labels.app }} er nede i {{ $labels.kubernetes_namespace }}","expr":"up{app=\"pt-sak-consumer\", job=\"kubernetes-pods\"} == 0","for":"2m"}]}}
            ]
        }
    }
}
pbpaste | curl     -X POST     -d@-     -H "Accept: application/vnd.github.ant-man-preview+json"     -u "x-access-token":"tokenme"     https://api.github.com/repos/navikt/kyrretest/deployments

Flytte til nais-org

Føler denne er knyttet tett opp til NAIS, noen grunn til at denne ikke bør være under nais-org?

Feature request: mulighet for å ha flere ressurser i VARS i nais/deploy/action

Slik det er nå er det ikke mulighet for å ha felles konfigurasjonsfiler for f.eks. prod og dev i dev.yaml og prod.yaml og overskrive disse individuelt per f.eks. cluster. Dette funker med CLIet, men ikke med GitHub Actions.

Som eksempel, gitt f.eks. disse filene:

Filer

dev.yaml

log_level: "debug"
port: "8080"
some_thing: "https://blah.org/"

dev-blah.yaml

port: 7000

Vil man kunne gjøre følgende i GitHub Actions for å gjøre det mulig å enkelt overskrive default verdier, i vårt tilfelle gå fra port 8080 til 7000 for en enkelt deploy.

    steps:
      - uses: nais/deploy/actions/deploy@v1
        env:
          RESOURCE: .nais/nais.yaml
-          VARS: .nais/${{ matrix.cluster }}.yaml
+          VARS: .nais/dev.yaml,.nais/${{ matrix.cluster }}.yaml

Med CLIet er det mulig å gjøre dette med deploy-nais --dry-run --print-payload --resource .nais/nais.yaml --vars .nais/dev.yaml --vars .nais/dev-blav.yaml

Move canary release testing out of GitHub

Background: GitHub actions is more unstable than the NAIS deploy service. False alerts are triggered when GHA cannot keep up with the deploy cron that runs every five minutes.

Task: Create a Cronjob in our prod-gcp cluster that performs the same orchestration as the .github/workflows/canary.yml workflow.

Docker push bør tilhøre deployfasen, ikke byggfasen

Ref. diagrammet i README.md:
bilde

Publisering av Docker image til f.eks. Docker Hub bør tilhøre "deploy phase", ikke "build phase". Ingen har vel bruk for et Docker image før de skal deploye? For den som liker å pushe ofte til feature-branches (som jeg gjøre) vil det bli mye bortkastet CPU, nettverkstrafikk og lagring.

Dette er vel samme issue som er registrert for orb-en: navikt/circleci-nais-orb#9

Feature request: Få med change-cause i deployment history

Er det mulig å gjøre noe med deploy via github actions, slik at følgende kommando:
kubectl rollout history deployment <appnavn> -n <teamnamespace>
kan gi tilbake noe mer beskrivende enn:

REVISION  CHANGE-CAUSE
1         <none>
2         <none>
3         <none>
...

?
F.eks git commit og/eller tidspunkt hadde vært nyttig (edited)

Skriv ut payload før validering i GHA deploy, ikke etter

Ved feil i payload i den nye deploy-mekanismen i GHA skrives bare en noe kryptisk feilmelding ut, selv med PRINT_PAYLOAD true
##[error]fatal: naiserator.yml: yaml: line 130: did not find expected key
Særlig ved bruk av templating er det vanskelig å se hvor denne linjen er. I CircleCI-orben ble payload skrevet ut tidligere, før vaidering, og det var lett å se hva som var feil, det samme bør gjøres her.

Pipeline stops working

Sometimes, hookd stops producing Kafka messages and needs to be restarted in order to start working again. This results in the entire pipeline becoming unusable.

Rette feil/mangler i henhold til krav i navikt/utvikling (funnet av roboten repo-linter)

Dette er en autogenerert issue, laget av et skript som går gjennom alle NAV sine kodebaser på Github og gjør diverse sjekker. Her er en liste over ting som må endres.

Kodebasen mangler en CODEOWNERS-fil

Dette er en fil som skal ligge i rotkatalogen, og angir hvilket team som eier kodebasen, på et maskinlesbart format. Den enkleste varianten, som vil holde for de fleste, er å ha en CODEOWNERS-fil som ser slik ut: (Merk at det skal være asterisk/stjerne foran navn på teamet!)

* @navikt/teamnavn

Gyldige teamnavn på Github er:

  • @navikt/academy (academy)
  • @navikt/ai (AI)
  • @navikt/alf (ALF)
  • @navikt/apen-kildekode (Åpen kildekode)
  • @navikt/arbeidsflate (Arbeidsflate)
  • @navikt/atom (atom)
  • @navikt/aura (aura)
  • @navikt/baseimage (baseimage)
  • @navikt/bidrag (Bidrag)
  • @navikt/biff (biff)
  • @navikt/bos (bos)
  • @navikt/bris (bris)
  • @navikt/core (Core)
  • @navikt/dagpenger (Dagpenger)
  • @navikt/database (database)
  • @navikt/datajegerne (datajegerne)
  • @navikt/dataplattform (dataplattform)
  • @navikt/design (Design)
  • @navikt/developers (Developers)
  • @navikt/di-pt-sak (di-pt-sak)
  • @navikt/didep (didep)
  • @navikt/digisos (DIGISOS)
  • @navikt/digisyfo (Digisyfo)
  • @navikt/dittnav (DittNAV)
  • @navikt/dolly-freg (Dolly-freg)
  • @navikt/drage (drage)
  • @navikt/drops (Drops)
  • @navikt/dsopkontroll (dsopkontroll)
  • @navikt/dusseldorf (dusseldorf)
  • @navikt/eessi-basis (EESSI Basis)
  • @navikt/eessi-pensjon (eessi pensjon)
  • @navikt/engineering-productivity (Engineering Productivity)
  • @navikt/europeisk-helsekort (Europeisk Helsekort)
  • @navikt/eux (eux)
  • @navikt/familie (familie)
  • @navikt/foreldrepenger (Foreldrepenger)
  • @navikt/forenklet-oppfolging (forenklet oppfølging)
  • @navikt/fp-faggruppe (fp-faggruppe)
  • @navikt/fpsak-frontend (FPSAK Frontend)
  • @navikt/gjenlevende (gjenlevende)
  • @navikt/helse (helse)
  • @navikt/identitet-sikkerhet (identitet-sikkerhet)
  • @navikt/idm (IDM)
  • @navikt/informasjon-og-veiledning (Informasjon og veiledning)
  • @navikt/infotrygd (Infotrygd)
  • @navikt/integrasjon (Integrasjon)
  • @navikt/intern-samhandling (Intern samhandling)
  • @navikt/jfb2019 (JFB2019)
  • @navikt/kafkaadmins (kafkaadmins)
  • @navikt/kuhr-helse (kuhr-helse)
  • @navikt/linuximage (linuximage)
  • @navikt/melosys (Melosys)
  • @navikt/melosys-java (melosys-java)
  • @navikt/mobilarbeidsplass (MobilArbeidsplass)
  • @navikt/nav-frontend-admins (nav-frontend-admins)
  • @navikt/nav-labs (NAV-labs)
  • @navikt/okonomi (Okonomi)
  • @navikt/onyx (onyx)
  • @navikt/opendata (opendata)
  • @navikt/oppfolging (Oppfølging)
  • @navikt/oppfolging-person (Oppfølging person)
  • @navikt/oppgavehandtering (Oppgavehåndtering)
  • @navikt/pam (PAM)
  • @navikt/pam-klan-j (pam-klan-j)
  • @navikt/pam-team-aasmund (pam-team-aasmund)
  • @navikt/pam-team-tuan (pam-team-tuan)
  • @navikt/paranoia (paranoia)
  • @navikt/pentest (pentest)
  • @navikt/personbruker (Personbruker)
  • @navikt/persondata (Persondata)
  • @navikt/personopplysninger (Personopplysninger)
  • @navikt/personoversikt (personoversikt)
  • @navikt/pesys (pesys)
  • @navikt/pim (pim)
  • @navikt/pus (pus)
  • @navikt/redaktorer (redaktører)
  • @navikt/samordning (samordning)
  • @navikt/selvbetjening-core (selvbetjening-core)
  • @navikt/sosialtjenester (Sosialtjenester)
  • @navikt/synt (Synt)
  • @navikt/tbd (tbd)
  • @navikt/team-arbeid (Team Arbeid)
  • @navikt/team-arena (Team Arena)
  • @navikt/team-oppfolging-fo (Team oppfølging - FO)
  • @navikt/team-register (Team Register)
  • @navikt/team-soknad (Team søknad)
  • @navikt/teampeon (teampeon)
  • @navikt/teamsykefravr (teamsykefravr)
  • @navikt/teamtag (teamtag)
  • @navikt/test_test (Test_Test)
  • @navikt/traktor (Traktor)
  • @navikt/warp (WARP)

Her er en oppdatert liste over team i Github.
Mangler teamet deres i lista? Ta kontakt med noen i Core-teamet på Github, så kan de opprette et team til dere.

Hvis det trengs spesielle tilpasninger, så ligger det mer dokumentasjon om CODEOWNERS-filformatet her:

https://help.github.com/articles/about-codeowners/

Når alle endringer er gjort, så kan denne saken lukkes.

Spørsmål og svar

Jeg har meninger om disse rådene - kan jeg komme med tilbakemeldinger?

Skriv i vei, på Slack-kanalen #open-source.

Kodebasen vår er ikke open source, derfor er det ikke noe poeng

Selv om koden i dag ikke er åpen for innsyn, så ta høyde for at den kan komme til å bli det i fremtiden. Uansett så vil forbedringene være til hjelp, enten kodebasen er åpen eller ei!

Hvem har ansvaret for å fikse det her?

Det er i utgangspunktet den/de/teamet som eier kodebasen som må fikse.

Det er en feil i rådene

Alle roboter gjør jo feil, denne også. Lag en issue på https://github.com/navikt/repo-linter.

Support parallel deployments to same cluster

Currently, deployment events to the GitHub Deployments API are sent using only the intended cluster as environment parameter. This works fine for teams only having single instances in each cluster, however results in two issues when attempting parallel deployments to the same cluster, that is, with different namespaces:

  1. The GitHub API receives two, parallel deployments to the same environment. Whichever deployment has its state set to success last will cause "all prior, non-transient and non-production environment deploys" to be set to inactive (as per https://developer.github.com/v3/repos/deployments/#inactive-deployments).
    This results in a state where the first deployment is seen as inactive which again results in the failure of the workflow as seen here: https://github.com/navikt/veiledearbeidssoker/runs/393003136

  2. The information shown in the GitHub deployments do not reflect the actual state of the deployments within the cluster, i.e. only the latest deployment to the cluster is shown as active even though multiple instances within the cluster are active (https://github.com/navikt/veiledearbeidssoker/deployments).

Proposed solution:
Append namespace to the environment property whenever a deployment contains a namespace other than default, e.g. dev-fss-q1

Fjerne støtte for default for GCP

GCP støtter ikke namespace default. Man burde få feilmelding hvis man prøver å deploye til det namespacet.

Ulempen er at dette er definert i nais.yaml.

Document Golden Path

The Golden path entails:

  • Be a manager of the Github Team you'd like to deploy as
  • Be an owner of the repository you'd like to deploy from
  • Register your repository/team connection at the deployment portal
  • Acquire credentials, either through a personal deploy key, or optionally a Github App
  • Use the deployment CLI in your pipeline

Push av Docker image dokumentert som en del av byggetrinnet

I README.md er push av image til Dockerhub tegnet inn som en del av byggetrinnet, ikke som en del av deploy.trinnet.

  1. Hva med #25?
  2. Er dette bare en upresis dokumentering eller er det slik bygging foregår?
  3. I det siste tilfellet, stemmer det at

Nav betaler for kapasitet på Circleci/Github Actions og Github Package Registry. Hvis du bruker 30 sekunder i hvert bygg for å pushe docker images så koster dette. Vi betaler pr machine hour på Circleci/Github Actions. Github Package Registry tar fulle images, det betyr at der pusher du hele imaget til Github hver gang. Sist mnd brukte vi opp båndbredden mot Github Package Registry. For dockerhub er ikke dette ett gigaproblem enda, de lagrer kun differ, dessuten tror jeg de henter inn penger andre steder.

Se på CUE basert spec deploy, linting

https://cuelang.org/

Step 1.

  • Lage eksempel-spec
  • Lage eksempel

Step 2.

  • Vurdere om det gir verdi
  • Spørre noen utviklere om de vil ha det

Step 3.

  • Implementere converter i hookd
  • Doc

Om vi går for noe som dette må vi ha enkel converter til yaml slik at man fortsatt kan gjøre kubectl apply uten å være avhengig av nais/deploy.

Litt mer tekst på deployment-siden

Deploymentsiden hvor du skal "søke" opp et repo, og så krysse av noen bokser er litt kryptisk. Kunne vi lagt til litt mer beskrivelse?

Også kunne gjerne søket vært slik at den ikke henter tilgjengelige repoer før jeg har søkt og trykt enter!

Feil Git commit hash vises i Github deployments

Skriver hookd alltid nyeste commit hash til Github, selv om det var ikke-nyeste commit som ble deployet?

Jeg jobber med å sette opp build & deploy pipeline med Travis CI og deployer en dummy/hello-world applikasjon med den. En feature jeg må lage er tilbakerulling, dvs. at det må være mulig å prodsette en gammel versjon av applikasjonen, en versjon som har blitt prodsatt før. Jeg prøver å bruke TravisCI sitt web-GUI til å restarte et gammelt bygg. Det ser i skrivende stund ut til å fungere, bortsett fra feil info om deployment-en i Github.

Det gjelder oversikten over deployments i Github-repoet mitt: https://github.com/navikt/person-arkiv/deployments . Når jeg restarter nest nyeste bygg i Travis CI (nest nyeste commit til master-branchen) blir deployment-oversikten i Github oppdatert, men Git commit hash-en i de nye deployment-ene tilhører nyeste commit, ikke nest nyeste.

Det ser ut som at Docker-imaget som faktisk blir deployet er det riktige (nest nyeste commit). Basert på at jeg får Travis til å bruke commit hash-en som tag på navnet til Docker imageet. Ser Docker image tag-en ved å kjøre kubectl describe ... på den nye k8s pod-en.

Travis: https://travis-ci.com/navikt/person-arkiv/builds

Bildet viser at selv om ikke-nyeste commit a02d9e7 har blitt deployet på nytt så er det nyeste commit b2bce85 som er registrert som deployet:
bilde

Hookd rapporterer ikke deployment failed til github

https://nav-it.slack.com/archives/C5KUST8N6/p1677154279434859

Jeg klarer ikke helt se hva som skjer her. Såvidt jeg kan skjønne så har deployd rapportert status tilbake til hookd, om at dette gikk galt. Videre så logget hookd deployment failed etter ett sekund eller noe, men hvorfor den ikke rapporterte det videre til github klarte jeg ikke finne ut av. Koden er litt for innviklet til at jeg helt klarer å grave meg tilbake til hvordan det skal fungere ...

Monitoring deployment rollout status

  • status=queued når deployment request (DR) er mottatt og lagt på Kafka
  • status=in_progress når DR er sendt til k8s
  • status=success når k8s rapporterer at rollout er successful
  • status=failure hvis k8s ikke tar imot ressursen
  • status=error når DR er feilformatert eller tilsvarende

Kræsjer om det er en tom variabel-fil

Satte opp en ny app og litt tilfeldig så ble det en vars.yaml som var tom i VARS-configen. Det ga denne feilen 😅

Ikke krise, men en litt hyggeligere feilmelding hadde vært vakkert.

[2024-03-06T09:20:52.649682161Z] NAIS deploy 2023-12-19-bbbb39b
[2024-03-06T09:20:52.649780403Z] This version was built 2023-12-19 14:24:02 +0000 UTC
[2024-03-06T09:20:52.649856374Z] Setting template variable 'image' to 'europe-north1-docker.pkg.dev/nais-management-233d/teamdagpenger/dp-manuell-behandling:2024.03.06-09.19-78d5286'
panic: assignment to entry in nil map

goroutine 1 [running]:
github.com/nais/deploy/pkg/deployclient.Prepare({0xe74ed8, 0xc00032c000}, 0xc0003[16](https://github.com/navikt/dp-manuell-behandling/actions/runs/8169657355/job/22334243243#step:4:17)000)
	/src/pkg/deployclient/deployer.go:61 +0x445
main.run()
	/src/cmd/deploy/main.go:48 +0x32f
main.main()
	/src/cmd/deploy/main.go:18 +0x[17](https://github.com/navikt/dp-manuell-behandling/actions/runs/8169657355/job/22334243243#step:4:18)

Feature request: Display k8s namespace in addition to cluster in Github Deployments activity log and 'active deployment' boxes

The deployments overview in my Github repository has an activity log and above that two boxes for active deployments to the k8s clusters prod-fss and dev-fss. In my build & deploy pipeline I deploy the same version of my app twice to dev-fss - to two seperate k8s namespaces - and once to prod-fss (to the default namespace). This is because some people think that when deploying to production I need to first deploy to a verification environment, then to the production environment and then to a production-like environment. The view in Github does not display this. A solution would be to display the namespace name in addition to the cluster name in the activity log. The same goes for the boxes for active deployments, but I guess this implies that we will have more boxes: one for each combination of cluster and namespace.

The image shows that my one Travis CI build resulted in three deployments, out of which only two get the status "active". (See the commit hashes.) There should be three active deployments. Two of these deployments were to seperate k8s namespaces in the dev-fss cluster.

bilde

Support for using deploy from Jenkins

After following this guide, the command that is used is:

docker run --rm \
  --env "NAIS_DEPLOY_KEY_DEV=$NAIS_DEPLOY_KEY_DEV" \
  --env "IMAGE=$IMAGE" \
  --env "HTTP_PROXY=http://webproxy-utvikler.nav.no:8088" \
  --env "HTTPS_PROXY=http://webproxy-utvikler.nav.no:8088" \
  -v $(pwd)/docker:/nais \
  navikt/deployment:v1 \
  /app/deploy \
    --apikey="$NAIS_DEPLOY_KEY_DEV" \
    --cluster="dev-fss" \
    --owner="navikt" \
    --repository="pesys-dummy" \
    --resource="/nais/naiserator-t4.yml" \
    --wait=true \
    ;

The HTTP proxy is needed because https://deployment.prod-sbs.nais.io/api/v1/deploy is not directly available from Jenkins servers. But this command fails, because of the less-than-ideal situation that the proxy server's certificate is self signed, and not trusted by the deploy tool.

Improve support for Mono Git repo setup (make environment variables from deploy.yml available in nais ?)

Hi, I have been trying to define a Mono Git Repos setup where I have multiple small microservices available in the same repo. In order to do that I defined 2 nais files and 2 Docker files one for each microservice. On top I have one deploy.yml file supplied with 2 deploy jobs one for each service.

https://github.com/navikt/pensjon-brev-bestilling/blob/features/PL-2357-add-prepare-brevdata/.github/workflows/deploy.yaml

Each nais.yml exposes a single interpolated variable {{image}}. This mean that I can not refer to the top level "env" variables IMAGE_BREV_BESTILLING and IMAGE_PREPARE_BREVDATA_GRUNNLAG direclt.

The work around is to assign each of this environment variables to the "IMAGE" variable from within each job:

env:
        IMAGE: ${{env.IMAGE_PREPARE_BREVDATA_GRUNNLAG}}


One way to improve this would be to make available the env variables to the nais.yml. Or if this is not desire to make available some pattern for variables f.ex. all variables starting with "IMAGE_%"

In the nais documentation when someone is reading it it is not imediatly clear that {{image}} is not environment variable and the example is very well placed for a Poly repositry , but it is not immediatly clear how would a Mono repo look like(especaly if the reader is convinced that image is env variable as I wasin the begining).

Maybe a addition to the documentation listing all "interpolated" variables would be nice.

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.