en
Språk
  • en
  • de
  • fr
  • es
  • br
  • ru
  • jp
  • kr
AI-översättning
  • ee
  • ae
  • cn
  • vn
  • id
  • eu
  • il
  • gr
  • no
  • fi
  • dk
  • se
  • tr
  • bg
  • nl
  • it
  • pl
  • hu
  • ro
  • ua
  • cs

Redmine i Kubernetes - Del 2: Installera Redmine

6/30/2020
8 minuter
Lukáš Beňa

Detta är den andra delen av serien om att distribuera Redmine i Kubernetes. I den här artikeln kommer vi att ge instruktioner om hur man distribuerar en pålitlig installation av Redmine.

Återberättande del 1

Nu måste du se fram emot installationen av Redmine på Kubernetes. När allt är det du kom för, eller hur?

In Redmine i Kubernetes - Del 1: Förbereda miljö, vi installerade Ingress Controller, en komponent för att omdirigera internetförfrågningar inuti ditt kluster, och vi skapade en DNS-domän, redminek8s.ddns.net. Nu behöver vi bara konfigurera HTTPS och vi är redo att distribuera Redmine.


HTTPS med cert-manager

Även om vi kan behålla vår Redmine som HTTP, har HTTPS blivit standarden för webbplatser, så mycket att de flesta webbläsare varnar dig för ett säkerhetsproblem när HTTPS inte används av en webbplats.

Att aktivera HTTPS är vanligtvis inte en trivial uppgift, eftersom du måste köpa ett certifikat och ladda upp det till din webbplats, förnya det efter en viss tid och upprepa processen. Cert-manager automatiserar allt detta, inklusive förnyelse av certifikat, och erhåller till och med gratis certifikat. Du kan se mer information om deras webbplats, men jag förklarar allt du behöver veta nästa.


Installera cert-manager

Utför följande steg för att installera cert-manager i ditt kluster:

rodret repo lägg till jetstack https://charts.jetstack.io && helm repo-uppdatering

helm install cert-manager jetstack / cert-manager - set installCRDs = true

Först lägger du till arkivet där cert-manager är, och sedan installerar du den senaste versionen.


Anslut till certifikatutfärdaren

Nu måste vi instruera cert-manager att ansluta till den certifikatleverantör som du väljer. Vi kommer att använda LetsEncrypt, en gratis certifikatmyndighet. Skapa den här filen först (kom ihåg att ersätta den med en riktig e-postadress) och namnge det cluster-issuer.yaml

Apiversion: cert-manager.io/v1alpha2

typ: ClusterIssuer

Metadata:

  namn: letsencrypt

spec:

  höjdpunkt:

    server: https://acme-v02.api.letsencrypt.org/directory

    e-post:

    PrivateKeysCretref:

      namn: letsencrypt

    lösare:

    - http01:

        inträde:

          klass: nginx

Använd sedan det på ditt kluster med

kubectl applicera -f cluster-emittent.yaml

Grattis! Filen ovan är den första kubernetes-konfigurationen vi skriver och tillämpar klustret. Du kanske har noterat att den visar hur du ansluter till LetsEncrypt, men den beskriver också Ingress Controller som vi skapade i del 1 (klassen: nginx i slutet) Den här typen av konfiguration har några rader med mellanslag för att indikera beroende av vissa egenskaper för andra. Förvara de utrymmen som visas för att se till att filen läses och tillämpas korrekt.

Nu är ditt kluster HTTPS aktiverat. När vi installerar ett program kan vi instruera det att fungera med HTTPS och voilà! Hela processen för att få certifikatet görs automatiskt bakom kulisserna.


Installera Redmine

Detta var vad vi alla väntade på. Vi kan installera Redmine på några olika sätt, men det överlägset mest praktiska är att använda Helm. Som vi redan gjorde tidigare, lägger vi först till arkivet där Redmine är

helm repo lägg till bitnami https://charts.bitnami.com/bitnami && helm repo-uppdatering

Men den här gången istället för att installera direkt kommer vi att skapa en konfigurationsfil för att ange något anpassat beteende som vi vill att Redmine ska ha.

Vi kommer att separera alla konfigurationer på deras eget avsnitt men du lägger dem alla i samma fil, en efter en. Ring filvärden.yaml.

Alla Helm-applikationer har en Values.yaml-fil med alla möjliga konfigurationer som kan göras för applikationen. När vi skapar våra egna värden. Vi definierar de förändringar vi vill ha. Allt värde som vi inte inkluderar i vår fil kommer att finnas kvar som det är i standardfilen.

Alla standardvärden kan också hittas på roderapplikationssidan, https://hub.helm.sh/charts/bitnami/redmine. Gå vidare och kolla alla konfigurationer.


Första Admin-användare

REDMINEUSERNAME: ADMINUSER

RedminePassword:

Detta steg är lika nödvändigt som lätt att förstå. Det är vår första användare på Redmine, den vi kommer att använda för att logga in för första gången.

När Redmine är installerat kan du komma åt den med den här användaren för att konfigurera din helt nya installation.


PostgreSQL-databas

Som standard kräver vår Helm-installation att en mariadb-databas ska skapas. Vi konfigurerar istället vår installation för att använda PostgreSQL. Du måste också lägga till minst ett lösenord för att komma åt denna databas, som du kan se nedan

DatabaseType: PostgreSQL

Mariadb:

  aktiverad: falsk

PostgreSQL:

  aktiverad: sant

  postgresqlDatabas: Redmine

  postgresql Användarnamn: Redmine

  postgresqlPassword:

Vi måste uttryckligen tala om för vår installation att vi inte vill att MariaDB ska installeras tillsammans med konfigurationen för PostgreSQL-databasen.


DNS-namnkonfiguration

Konfigurationen nedan är den andra sidan av DNS-konfigurationen som vi gjorde i del 1. Som ni kan se aktiverar vi TLS, protokollet bakom HTTPS, och ställer in värdnamnet vi använde när vi skapade vår DNS-post:

inträde:

  aktiverad: sant

  certManager: sant

  värdnamn: redminek8s.ddns.net

  tls: sant

  annoteringar:

    kubernetes.io/ingress.class: nginx

    Cert-manager.io/cluster-issuer: LETSENCRYPT

Också i de två sista linjerna länkar vi vår applikation med Ingress Controller och med Cluster Issuer som vi skapade tidigare.

Nu kan vi distribuera Redmine med vår anpassade konfiguration:

helm installera Redmine -f Values.yaml bitnami / redmine

Den linjen liknar andra roderinstallationslinjer som vi använde tidigare, men den här gången tillhandahåller vi anpassade värden. Detta är sättet att anpassa alla Helm-applikationer.

Vi behöver fortfarande lite tålamod eftersom applikationen tar lite tid. Du kan köra det här kommandot för att kontrollera statusen för dina applikationsbehållare:

kubectl få skidor - klocka

Kommandot returnerar något liknande det här:

NAMN KLAR STATUS ÅTERSTART Åldern

. . .

redmine-999c68dd9-x7h2k    1/1     Running   0          6m40s

redmine-postgresql-0 1/1 Running 0 6m40s

Du måste vänta tills statusen för båda containrarna är igång och alla är redo 1/1, vilket i mitt fall tog cirka 6 minuter.

Nu är allt redo att öppna webbläsaren och gå till vår nya distribution:

Redmine är redo


Inslagning upp

Kubernetes är ett komplext verktyg för att distribuera applikationer, men vi navigerade genom den komplexiteten med hjälp av Helm (ingen ordning avsedd) och implementerade en pålitlig installation av Redmine.

Du kan hitta en sammanfattning av hur du gör i följande git repo: https://github.com/lcofre/redmine-on-k8s. Jämför gärna med dina filer om du fastnar.

Vi lämnade några begrepp ur diskussionen eftersom de var komplexa eller förklaringen var molnspecifik. Bland dem finns din applikations livskraft och beredskap, inkommande mejlkonfiguration och utskalning för att hantera mer belastning. Meddela oss nedan vad som intresserar dig mest så att vi kan diskutera det i framtiden.

Den ultimata Redmine -uppgraderingen? Lätt.

Få alla kraftfulla verktyg för perfekt projektplanering, hantering och kontroll i en programvara.

Prova Easy Redmine i 30 dagars gratis provperiod

Fullständiga funktioner, SSL-skyddad, dagliga säkerhetskopior, i din geolokalisering