Du sätter upp en Linux-server, lovar dig själv att ”den här ska bli felfri”, och så försvinner en eftermiddag på att installera om Docker, koppla upp övervakning och leta upp det enda kommandot du glömde förra gången. Det är inte svårt. Det är bara samma jobb om och om igen.
Den här Docker Grafana-automationen träffar DevOps-ansvariga först, men byråägare som levererar kundmiljöer och solo-grundare som kör produktion med minimal budget känner av det lika mycket. Resultatet är enkelt: du får en konsekvent stack (Docker, K3s, Jenkins, Prometheus, Grafana) med färre missade steg och tryggare överlämningar.
Nedan ser du vad arbetsflödet gör, var tidsvinsterna faktiskt kommer ifrån och vad du bör tänka på innan du kör det mot en riktig server.
Så fungerar den här automationslösningen
Se hur det här löser problemet:
n8n Workflow Template: Docker + Grafana: enhetliga Linuxservrar snabbare
flowchart LR
subgraph sg0["Start DevOps Setup Flow"]
direction LR
n0@{ icon: "mdi:play-circle", form: "rounded", label: "Start DevOps Setup", pos: "b", h: 48 }
n1@{ icon: "mdi:swap-vertical", form: "rounded", label: "Configure Parameters", pos: "b", h: 48 }
n2@{ icon: "mdi:cog", form: "rounded", label: "System Preparation", pos: "b", h: 48 }
n3@{ icon: "mdi:cog", form: "rounded", label: "Install Docker", pos: "b", h: 48 }
n4@{ icon: "mdi:cog", form: "rounded", label: "Install Kubernetes", pos: "b", h: 48 }
n5@{ icon: "mdi:cog", form: "rounded", label: "Install Jenkins", pos: "b", h: 48 }
n6@{ icon: "mdi:cog", form: "rounded", label: "Install Monitoring", pos: "b", h: 48 }
n7@{ icon: "mdi:cog", form: "rounded", label: "Create DevOps User", pos: "b", h: 48 }
n8@{ icon: "mdi:cog", form: "rounded", label: "Security Configuration", pos: "b", h: 48 }
n9@{ icon: "mdi:cog", form: "rounded", label: "Final Configuration", pos: "b", h: 48 }
n10@{ icon: "mdi:swap-vertical", form: "rounded", label: "Setup Complete", pos: "b", h: 48 }
n11@{ icon: "mdi:cog", form: "rounded", label: "Wait", pos: "b", h: 48 }
n11 --> n2
n3 --> n4
n5 --> n6
n7 --> n8
n4 --> n5
n6 --> n7
n0 --> n1
n2 --> n3
n9 --> n10
n1 --> n11
n8 --> n9
end
%% Styling
classDef trigger fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
classDef ai fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
classDef aiModel fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px
classDef decision fill:#fff8e1,stroke:#f9a825,stroke-width:2px
classDef database fill:#fce4ec,stroke:#c2185b,stroke-width:2px
classDef api fill:#fff3e0,stroke:#e65100,stroke-width:2px
classDef code fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
classDef disabled stroke-dasharray: 5 5,opacity: 0.5
class n0 trigger
Utmaningen: repeterbar serveruppsättning utan överraskningar
Serverbyggen är fulla av steg som är ”nästan samma”. Du uppdaterar paket, installerar Docker, justerar rättigheter, lägger till en användare, kopplar på Jenkins och till sist övervakning med Prometheus och Grafana. Första gången är det lugnt. Tredje gången är det slit, eftersom små skillnader smyger sig in. En server har en annan Docker-version. En annan har K3s installerat men saknar Helm. Sedan sker överlämningen och någon frågar: ”Vad är admin-URL:en nu igen?” och du skrollar i terminalhistorik som om det vore en deckare.
Det eskalerar snabbt. Här är var det faller isär.
- Manuell provisionering blir en 2-timmars checklista som ändå missar små steg, särskilt under press.
- Verktygsversioner glider isär mellan servrar, vilket gör felsökning oförutsägbar och bromsar varje driftsättning.
- Säkerhetshärdning skjuts upp ”till senare”, och senare blir ofta aldrig.
- Överlämningar blir röriga eftersom viktiga detaljer ligger i någons anteckningar i stället för i en repeterbar körning.
Lösningen: ett arbetsflöde som provisionerar hela DevOps-verktygslådan
Det här n8n-arbetsflödet gör ditt serverbygge till en enda, repeterbar infrastrukturrunda. Du startar det manuellt, anger serverhost, SSH-användare och de versioner du vill installera och låter sedan arbetsflödet driva processen. Det ansluter via SSH för att uppdatera grundsystemet, installerar Docker Engine samt Docker Compose och sätter sedan upp ett lättvikts-Kubernetes-kluster med K3s tillsammans med verktygen du brukar behöva direkt efter (kubectl, Helm, k9s). Därefter konfigurerar det Jenkins med Docker-integration, driftsätter Prometheus och Grafana via Helm charts och avslutar med att skapa en dedikerad ops-användare och tillämpa grundläggande härdning. På slutet får du en felfri sammanfattning ”setup klar” så att nästa person slipper gissa.
Arbetsflödet börjar med en kort fördröjningsspärr (praktiskt när du koordinerar att servern är redo) och kör sedan en sekvens av SSH-skript i rätt ordning. Till sist skriver det ut en färdig sammanfattning som du kan klistra in i ett ärende, en runbook eller ett överlämningsmejl till kund.
Vad som förändras: före vs. efter
| Det här eliminerar | Effekten du märker |
|---|---|
|
|
Effekt i verkligheten
Säg att du provisionerar 3 nya Linux-servrar på en månad (nya kunder, staging, ersättningsservrar). Manuellt består en typisk ”full stack”-uppsättning av ungefär 10 uppgifter à cirka 10 minuter, plus omarbete och kontroller, så du hamnar lätt på runt 2 timmar per server. Med det här arbetsflödet lägger du kanske 10 minuter på att fylla i indata och följa körningen och sedan 10 minuter till på att verifiera åtkomst och spara sammanfattningen. Det är ungefär 90 minuter tillbaka per server, och det blir stabilt arbete i stället för stressarbete.
Krav
- n8n-instans (prova n8n Cloud gratis)
- Self-hosting-alternativ om du föredrar det (Hostinger fungerar bra)
- Linux-server för att provisionera Docker, K3s och verktyg
- SSH-åtkomst för att köra installationskommandon
- Root-behörighet (eller sudo) för systeminstallationer
Kunskapsnivå: Medel. Du bör vara bekväm med SSH, grundläggande Linux-administration och att uppdatera autentiseringsuppgifter på ett säkert sätt.
Behöver du hjälp att implementera detta? Prata med en automationsexpert (gratis 15-minuters konsultation).
Flödet i arbetsflödet
Du startar en infrastrukturrunda. Den startar manuellt, vilket är användbart när du vill ha en människa i loopen för produktionsservrar eller kundmiljöer.
Du anger serverdetaljer och verktygsversioner. I ”Set Provisioning Inputs” definierar du serverhost, SSH-användarnamn/lösenord, Docker- och K3s-versioner samt ops-användarens inloggning som ska skapas.
Arbetsflödet förbereder systemet och installerar sedan kärnstacken. En wait-nod fungerar som en kort spärr, därefter ansluter arbetsflödet via SSH för att uppdatera paket, installera Docker Engine och Compose, installera ett K3s-kluster och sätta upp Jenkins i rätt ordning.
Övervakning och härdning sker innan slutlig överlämning. Prometheus och Grafana provisioneras (via Helm), ett ops-konto skapas med rätt behörigheter och säkerhetsinställningar tillämpas så att servern inte lämnas i ett ”tillfälligt” läge.
Du kan enkelt ändra verktygsversioner för att matcha din standard, eller skärpa säkerhetsstandarder för striktare miljöer. Se hela implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementering
Steg 1: konfigurera den manuella triggern
Det här arbetsflödet startar manuellt och skickar sedan indata för provisionering vidare i automationskedjan.
- Lägg till noden Begin Infrastructure Run som trigger.
- Anslut Begin Infrastructure Run till Set Provisioning Inputs.
Steg 2: anslut indata-konfigurationen
Definiera standardvärden för server, Kubernetes och användare som ska användas genomgående i alla provisioneringskommandon.
- Öppna Set Provisioning Inputs och ställ in server_host till
={{ $json.server_host || '192.168.1.100' }}. - Ställ in server_user till
{{ $json.server_user || 'root' }}och server_password till{{ $json.server_password || 'your_password' }}. - Ställ in docker_version till
{{ $json.docker_version || 'latest' }}och k8s_version till{{ $json.k8s_version || '1.28' }}. - Ställ in devops_user till
{{ $json.devops_user || 'devops' }}, user_password till{{ $json.user_password || 'devops123' }}och cluster_name till{{ $json.cluster_name || 'devops-cluster' }}. - Anslut Set Provisioning Inputs till Delay Gate, och därefter till Prepare Base System.
[CONFIGURE_YOUR_API_KEY]. Ersätt dessa i Prepare Base System och Install Jenkins Server innan ni kör arbetsflödet.Steg 3: konfigurera SSH-inloggningsuppgifter för provisionering
Alla provisioneringsuppgifter körs via SSH och kräver en anslutning med privat nyckel till målservern.
- Öppna Prepare Base System och bekräfta att Authentication är inställt på
privateKey. - Inloggningsuppgifter krävs: Anslut era sshPrivateKey-inloggningsuppgifter i Prepare Base System.
- Tillämpa samma sshPrivateKey-inloggningsuppgifter på alla SSH-noder: Deploy Docker Engine, Deploy K3s Cluster, Install Jenkins Server, Provision Monitoring Stack, Create Ops Account, Harden Security Settings och Finalize Stack Setup.
Steg 4: konfigurera provisioneringssekvensen
Det här arbetsflödet körs i en strikt sekvens för att förbereda bassystemet, driftsätta Docker och Kubernetes och därefter installera DevOps-stacken.
- I Prepare Base System, verifiera att kommandoblocket uppdaterar operativsystemet och installerar nödvändiga paket.
- Anslut Prepare Base System → Deploy Docker Engine → Deploy K3s Cluster → Install Jenkins Server → Provision Monitoring Stack.
- Fortsätt flödet med Create Ops Account → Harden Security Settings → Finalize Stack Setup.
- I Deploy K3s Cluster, behåll Kubernetes-versionsuttrycket intakt:
v{{ $json.k8s_version }}.0+k3s1.
Steg 5: konfigurera utdata för sammanfattning vid slutförande
Skapa en sammanfattande payload för att bekräfta provisioneringsdetaljer och åtkomst-URL:er.
- Öppna Completion Summary och ställ in setup_status till
✅ DevOps Stack Setup Complete!. - Ställ in server_info till
Host: {{ $('Set Provisioning Inputs').item.json.server_host }}. - Ställ in devops_user till
Username: {{ $('Set Provisioning Inputs').item.json.devops_user }}och user_password tillPassword: {{ $('Set Provisioning Inputs').item.json.user_password }}. - Ställ in jenkins_url till
http://{{ $('Set Provisioning Inputs').item.json.server_host }}:8080, grafana_url tillhttp://{{ $('Set Provisioning Inputs').item.json.server_host }}:3000och prometheus_url tillhttp://{{ $('Set Provisioning Inputs').item.json.server_host }}:9090.
Steg 6: testa och aktivera ert arbetsflöde
Kör en manuell exekvering för att validera SSH-anslutning och bekräfta att alla tjänster installeras korrekt.
- Klicka på Execute Workflow på Begin Infrastructure Run för att starta provisioneringskedjan.
- Bekräfta att varje SSH-nod slutförs utan fel och granska terminalutdata efter eventuella paket- eller tjänstfel.
- Verifiera att slututdata från Completion Summary innehåller URL:er och inloggningsuppgifter för Jenkins, Grafana och Prometheus.
- När körningen är lyckad, växla arbetsflödet till Active för användning i produktion.
Se upp med
- SSH-uppgifter kan gå ut eller kräva specifika rättigheter. Om det skapar fel, kontrollera serverns auth-loggar (och din credential-post i n8n) först.
- Om du använder wait-noder eller extern rendering varierar processtiderna. Öka väntetiden om nedströmsnoder fallerar på tomma svar.
- Standardprompter i AI-noder är generiska. Lägg in din tonalitet tidigt, annars kommer du att redigera utdata i all evighet.
Vanliga frågor
Cirka 30 minuter när du har SSH-åtkomst och autentiseringsuppgifter redo.
Nej. Du behöver inte koda, men du måste förstå serveråtkomst, behörigheter och vad det innebär att köra installationer som root.
Ja. n8n har ett gratis self-hosted-alternativ och en gratis provperiod på n8n Cloud. Cloud-planer startar på 20 $/månad för högre volym. Du behöver också räkna in dina server/VPS-kostnader (och eventuella cloud-CLI:er du väljer att använda).
Två alternativ: n8n Cloud (managed, enklast att komma igång) eller self-hosting på en VPS. För self-hosting är Hostinger VPS prisvärd och hanterar n8n bra. Self-hosting ger dig obegränsade körningar men kräver grundläggande serverdrift.
Börja i ”Set Provisioning Inputs” och ändra Docker/K3s-versioner, användarnamn och lösenord så att de matchar din standard. Om du inte vill ha Jenkins på varje server kan du inaktivera SSH-steget ”Install Jenkins Server” och ändå behålla Docker, K3s och övervakningsstacken. Team justerar också ”Harden Security Settings” så att det matchar deras brandväggspolicy, eller ändrar ”Delay Gate” när provisioneringen behöver extra tid för DNS eller instansstart.
Oftast är det fel host/användare, ett utgånget lösenord eller att servern blockerar SSH med brandväggsregler. Bekräfta först att du kan SSH:a från din egen dator och uppdatera sedan samma uppgifter i n8n. Om du använder nyckelbaserad autentisering, säkerställ att nyckeln finns i n8n-credential och att fjärranvändaren har rätt sudo-behörigheter.
Om du self-hostar n8n finns ingen körningsgräns; det beror främst på din serverstorlek och hur många körningar du gör parallellt. I n8n Cloud baseras planbegränsningar på månatliga körningar, så det är bäst att använda det för kontrollerade provisioneringskörningar (några per vecka) snarare än konstant, högfrekvent användning. I praktiken är arbetsflödet byggt för att hantera en server åt gången eftersom det kör långa SSH-installationssekvenser. Om du behöver provisionera många servrar kan du batcha dem genom att mata in en lista med hostar och använda split-in-batches, men du vill fortfarande strypa parallelliteten så att du inte överbelastar nätverket eller slår i begränsningar på paket-spegelservrar.
För serverprovisionering, ja, men med kontext. n8n hanterar längre flöden, förgreningar och SSH-driven automation, vilket är krångligt (eller omöjligt) i många Zapier-liknande verktyg. Du får också möjligheten att self-hosta, vilket är viktigt när du vill ha obegränsade körningar eller striktare kontroll över autentiseringsuppgifter. Zapier eller Make kan fortfarande fungera för lätta notifieringar runt provisionering, som ”servern är klar”-mejl, men de passar dåligt för att köra installationerna i sig. Prata med en automationsexpert om du vill ha hjälp att välja rätt uppdelning.
Konsekventa servrar är tråkiga, och det är hela poängen. Kör en gång, spara sammanfattningen och sluta bygga om samma stack ur minnet.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.