Nytt: contrib.gathering.org

Jeg vekket akkurat contrib.gathering.org til live, men dette blir en to-delt blog-post.

Hva er contrib.gathering.org?

La oss begynne med det viktigste: contrib.gathering.org er en samling linker til ting som er løst relatert til TG. Jeg håper lista vil eksplodere, etter hvert som alle dere der ute som lager ting får lagt til innholdet deres. Hjelp oss!

Den enkleste måten å gjøre det på er via github. Helst kan du lage en pull request, men et vanlig issue virker selvsagt også.

Vi håper å få samlet så mye artige linker (relatert til TG som mulig). Bildegallerier, konkuransebidrag, eller hva det måtte være. Bruk fantasien!

Del to: Deploy

Den andre delen av denne posten er stacken som ligger bak. Tidligere har alt vi hoster på TG stort sett ligget på den samme enorme serveren, men nylig har vi begynt å bevege oss over i litt mer moderne metoder. Contrib er foreløpig den desidert mest moderne pipelinen vi har. Den vil forhåpentligvis være et positivt bidrag for å få flyttet andre, viktigere websider over til mer moderne og fleksible utviklingsmiljøer.

Selve biten med rst2html og sånt for å generere html er ganske lite interessant.

Det som er artig er at dette kjører på Kubernetes. I dag kjører det på Google Cloud, men det kan selvsagt kjøre andre steder også – vi prøver ut Google Cloud først.

For å deploye til “prod” er alt vi trenger å gjøre i dag å comitte til master-branchen i git, når det skjer så trigges en automatisk bygg i Google Cloud, som avslutter med å gjøre en deploy i kubernetes-clusteret (også i google cloud). Denne deployen gjøres med en rolling update.

I dette tilfellet er det forholdsvis overkill, siden det ikke er noe kode bak – bare statiske filer – men det er en fin test, og vil gjenbrukes for andre prosjekter.

For de interesserte så ligger alt for deployment i samme git-repo. En rask gjennomgang:

~~~~.text

• /Dockerfile – Denne brukes til å bygge en
  container, den kan kjøres på din lokale laptop om du vil
• /cloudbuild.yaml – Dette brukes av den automatiske
  byggeprosessen. Kort fortalt definerer den at ved
  en ny git commit skal det gjennomføres en docker build,
  push og kubernetes deploy.
• /k8s/ – Dette er ressursene som er lagt opp i Kubernetes.
  De er i utgangspunktet bare lagt til en gang for hånd,
  eller ved endringer.
• /k8s/deploy.yaml – dette er selve deploymentfila, som i
  praksis bare definerer hvilket image vi skal bruke. Imaget
  oppdateres automatisk av byggescriptet.
• /k8s/service.yaml – Her gjør vi deploymenten tilgjengelig for
  andre tjenester i clusteret
• /k8s/ingress.yaml – Denne definerer at tjenesten skal
  eksponeres på internett, via “ingress”-tjenesten. Den
  spesifiserer domenet, og ber om SSL-terminering, via
  let’s encrypt.

~~~~
(Jadda, flott med en blog der bullet points er brukket)

Det som ikke ligger i det repoet er resten av infrastrukturen: ingress-kontrolleren og let’s encrypt automatikken. Dette kan det hende det kommer mer om når det faktisk er 100% ferdig. Teknisk sett kjører alt dette på min personlige gcloud-konto/cluster i dag…. Fordi jeg glemte igjen login/passord til KANDU/TG sin konto på jobben (… glemte “pass git push”, for de nysgjerrige).