sql >> Databasteknik >  >> RDS >> PostgreSQL

Automatisera PostgreSQL dagliga uppgifter med Jenkins

Den här bloggen är en kort presentation om Jenkins och visar dig hur du använder det här verktyget för att hjälpa dig med några av dina dagliga PostgreSQL-administration och hanteringsuppgifter.

Om Jenkins

Jenkins är en programvara med öppen källkod för automatisering. Det är utvecklat i java och är ett av de mest populära verktygen för kontinuerlig integration (CI) och kontinuerlig leverans (CD).

2010, efter förvärvet av Sun Microsystems av Oracle, var "Hudson"-programvaran i en tvist med sin öppen källkodsgemenskap. Denna tvist blev grunden för lanseringen av Jenkins-projektet.

Nuförtiden är "Hudson" (Eclipse offentlig licens) och "Jenkins" (MIT-licens) två aktiva och oberoende projekt med ett mycket liknande syfte.

Jenkins har tusentals plugins som du kan använda för att påskynda utvecklingsfasen genom automatisering under hela utvecklingens livscykel; bygga, dokumentera, testa, paketera, steg och driftsättning.

Vad gör Jenkins?

Även om den huvudsakliga användningen av Jenkins kan vara Continuous Integration (CI) och Continuous Delivery (CD), har denna öppen källkod en uppsättning funktioner och den kan användas utan något åtagande eller beroende av CI eller CD, så Jenkins presenterar några intressanta funktioner för att utforska:

  • Schemalägg periodjobb (istället för att använda den traditionella crontab )
  • Övervaka jobb, dess loggar och aktiviteter med en ren vy (eftersom de har ett alternativ för gruppering)
  • Underhåll av jobb kan göras enkelt; förutsatt att Jenkins har en uppsättning alternativ för det
  • Konfigurera och schemalägga installation av programvara (genom att använda Puppet) i samma värd eller i en annan.
  • Publicera rapporter och skicka e-postmeddelanden

Köra PostgreSQL-uppgifter i Jenkins

Det finns tre vanliga uppgifter som en PostgreSQL-utvecklare eller databasadministratör måste göra dagligen:

  1. Schemaläggning och exekvering av PostgreSQL-skript
  2. Exekvera en PostgreSQL-process som består av tre eller flera skript
  3. Kontinuerlig integration (CI) för PL/pgSQL-utvecklingar

För utförandet av dessa exempel antas det att Jenkins och PostgreSQL (åtminstone version 9.5) servrar är installerade och fungerar korrekt.

Schemaläggning och exekvering av ett PostgreSQL-skript

I de flesta fall implementering av dagliga (eller periodiskt) PostgreSQL-skript för att utföra en vanlig uppgift som...

  • Generering av säkerhetskopior
  • Testa återställningen av en säkerhetskopia
  • Körning av en fråga i rapporteringssyfte
  • Rensa upp och arkivera loggfiler
  • Anropar en PL/pgSQL-procedur för att rensa tabeller

t definieras på crontab :

0 5,17 * * * /filesystem/scripts/archive_logs.sh
0 2 * * * /db/scripts/db_backup.sh
0 6 * * * /db/data/scripts/backup_client_tables.sh
0 4 * * * /db/scripts/Test_db_restore.sh
*/10 * * * * /db/scripts/monitor.sh
0 4 * * * /db/data/scripts/queries.sh
0 4 * * * /db/scripts/data_extraction.sh
0 5 * * * /db/scripts/data_import.sh
0 */4 * * * /db/data/scripts/report.sh

Som crontab är inte det bästa användarvänliga verktyget för att hantera den här typen av schemaläggning, det kan göras på Jenkins med följande fördelar...

  • Mycket vänligt gränssnitt för att övervaka deras framsteg och nuvarande status
  • Loggarna är omedelbart tillgängliga och du behöver inget särskilt tillstånd för att komma åt dem
  • Jobbet skulle kunna köras manuellt på Jenkins istället för att ha en schemaläggning
  • För någon sorts jobb behöver du inte definiera användare och lösenord i vanliga textfiler eftersom Jenkins gör det på ett säkert sätt
  • Jobben kan definieras som en API-körning

Så det kan vara en bra lösning att migrera jobb relaterade till PostgreSQL-uppgifter till Jenkins istället för crontab.

Å andra sidan har de flesta databasadministratörer och utvecklare starka kunskaper i skriptspråk och det skulle vara lätt för dem att utveckla små gränssnitt för att hantera dessa skript för att implementera de automatiserade processerna med målet att förbättra sina uppgifter. Men kom ihåg att Jenkins sannolikt redan har en uppsättning funktioner för att göra det och dessa funktioner kan göra livet enkelt för utvecklare som väljer att använda dem.

För att definiera exekveringen av skriptet är det därför nödvändigt att skapa ett nytt jobb genom att välja alternativet "Nytt objekt".

Figur 1 – "Nytt objekt" för att definiera ett jobb för att exekvera ett PostgreSQL-skript

Sedan, efter att ha namngett det, välj typen "FreeStyle-projekt" och klicka på OK.

Figur 2 – Val av jobbtyp (artikel)

För att slutföra skapandet av detta nya jobb, i avsnittet "Bygg" måste alternativet "Kör skript" väljas och i kommandoradsrutan sökvägen och parametreringen av skriptet som kommer att köras:

Figur 3 – Specifikation av kommandot som ska köras

För den här typen av jobb är det tillrådligt att verifiera skriptbehörigheter, eftersom åtminstone körning för gruppen som filen tillhör och för alla måste ställas in.

I det här exemplet är skriptet query.sh har läs- och körbehörigheter för alla, läs- och körbehörigheter för gruppen och läs skriv och kör för användaren:

[email protected]:~/db/scripts$ ls -l query.sh
-rwxr-xr-x 1 slonik slonik 365 May 11 20:01 query.sh
[email protected]:~/db/scripts$ 

Det här skriptet har en mycket enkel uppsättning satser, anropar i princip bara verktyget psql för att köra frågor:

#!/bin/bash

/usr/lib/postgresql/10/bin/psql -U report -d db_deploy -c "select * from appl" > /home/slonik/db/scripts/appl.dat
 
/usr/lib/postgresql/10/bin/psql -U report -d db_deploy -c "select * from appl_users" > /home/slonik/db/scripts/appl_user.dat
 
/usr/lib/postgresql/10/bin/psql -U report -d db_deploy -c "select * from appl_rights" > /home/slonik/db/scripts/appl_rights.dat

Exekvera en PostgreSQL-process som består av tre eller fler skript

I det här exemplet kommer jag att beskriva vad du behöver för att köra tre olika skript för att dölja känslig data och för det kommer vi att följa stegen nedan...

  • Importera data från filer
  • Förbered data för att maskeras
  • Säkerhetskopiering av databas med maskerad data

Så för att definiera detta nya jobb är det nödvändigt att välja alternativet "New Item" på Jenkins huvudsida och sedan, efter att ha tilldelat ett namn, måste alternativet "Pipeline" väljas:

Figur 5 - Pipeline-objekt i Jenkins

När jobbet har sparats i avsnittet "Pipeline", på fliken "Avancerade projektalternativ", måste fältet "Definition" ställas in på "Pipeline script", som visas nedan:

Figur 6 - Groovy script i pipeline avsnitt

Som jag nämnde i början av kapitlet, det använda Groovy-manuset är sammansatt av tre steg, det betyder tre distinkta delar (stadier), som presenteras i följande manus:

def dir_live1='/data/ftp/server1'
def dir_live2='/data/ftp/server2'

pipeline{
    agent any
    stages
    {
      stage('Import data from files'){
          steps{
              echo "Import data from ${dir_live1} ..."
              sh script :"/home/slonik/db/scripts/import_data_from_files.sh ${dir_live1}"
              echo "Import data from $dir_live2 ..."
              sh script :"/home/slonik/db/scripts/import_data_from_files.sh ${dir_live2}"
          }
      }
      stage('Prepare data to be masked'){
          steps{
              echo "Purge data ..."
              sh script :"/home/slonik/db/scripts/purge_data.sh"
              echo "Mask data ..."
              sh script :"/home/slonik/db/scripts/mask_data.sh"
          }
      }
     stage('Backup of database with data masked'){
          steps{
              echo "Backup database after masking ..."
              sh script :"/home/slonik/db/scripts/backup_db.sh"
          }
      } 
        
    }
}

Groovy är ett Java-syntax-kompatibelt objektorienterat programmeringsspråk för Java-plattformen. Det är både ett statiskt och dynamiskt språk med funktioner som liknar Python, Ruby, Perl och Smalltalk.

Det är lätt att förstå eftersom den här typen av manus är baserat på några uttalanden...

Scen

Betyder de 3 processerna som kommer att exekveras:"Importera data från filer", "Förbered data för att maskeras"

och "Säkerhetskopiering av databas med maskerad data".

Steg

Ett "steg" (ofta kallat ett "byggsteg") är en enskild uppgift som är en del av en sekvens. Varje steg kan bestå av flera steg. I det här exemplet har det första steget två steg.

sh script :"/home/slonik/db/scripts/import_data_from_files.sh '/data/ftp/server1'

sh script :"/home/slonik/db/scripts/import_data_from_files.sh '/data/ftp/server2'

Data importeras från två distinkta källor.

I det föregående exemplet är det viktigt att notera att det finns två variabler definierade i början och med en global räckvidd:

dir_live1
dir_live2

Skripten som används i dessa tre steg anropar psql , pg_restore och pg_dump verktyg.

När jobbet är definierat är det dags att utföra det och för det är det bara nödvändigt att klicka på alternativet "Bygg nu":

Figur 7 – Exekveringsjobb

Efter att bygget startar är det möjligt att verifiera dess framsteg.

Figur 8 – Startar “Build”

Pipeline Stage View-plugin inkluderar en utökad visualisering av Pipeline-bygghistorik på indexsidan för ett flödesprojekt under Stage View. Denna vy skapas så snart uppgifterna är slutförda och varje uppgift representeras av kolumn från vänster till höger och det är möjligt att se och jämföra den förflutna tiden för servalkörningarna (känd som en Build in Jenkins).

När exekveringen (även kallad Build) är klar är det möjligt att få ytterligare information genom att klicka på den färdiga tråden (röd ruta).

Figur 9 – Starta “Build”

och sedan i alternativet "Konsolutdata".

Figur 10 – Konsolutdata

De tidigare vyerna är extremt användbara eftersom de gör det möjligt att få en uppfattning om körtiden som krävs för varje steg.

Pipelines, även känd som arbetsflöde, det är ett plugin som tillåter definitionen av applikationens livscykel och det är en funktion som används i Jenkins för kontinuerlig leverans (CD). i åtanke.

Det här exemplet är till för att dölja känslig data, men det finns säkert många andra exempel på en daglig basis av PostgreSQL-databasadministratör som kan köras på ett pipeline-jobb.

Pipeline har funnits på Jenkins sedan version 2.0 och det är en otrolig lösning!

Kontinuerlig integration (CI) för PL/pgSQL-utvecklingar

Den kontinuerliga integrationen för databasutveckling är inte lika lätt som i andra programmeringsspråk på grund av data som kan gå förlorade, så det är inte lätt att hålla databasen i källkontroll och distribuera den på en dedikerad server, särskilt när det finns skript som innehåller DDL (Data Definition Language) och DML (Data Manipulation Language)-satser. Detta beror på att den här typen av uttalanden modifierar databasens nuvarande tillstånd och till skillnad från andra programmeringsspråk finns det ingen källkod att kompilera.

Å andra sidan finns det en uppsättning databassatser där det är möjligt med kontinuerlig integration som för andra programmeringsspråk.

Det här exemplet är endast baserat på utveckling av procedurer och det kommer att illustrera utlösningen av en uppsättning tester (skrivna i Python) av Jenkins när PostgreSQL-skript, på vilka koden för följande funktioner lagras, har begåtts i ett kodlager.

Figur 11 – PLpg/SQL-funktioner

Dessa funktioner är enkla och dess innehåll har bara ett fåtal logik eller en fråga i PLpg/SQL eller plperlu språk som funktionen f_IsValidEmail :

CREATE OR REPLACE FUNCTION f_IsValidEmail(email text) RETURNS bool
LANGUAGE plperlu
AS $$
use Email::Address;
my @addresses = Email::Address->parse($_[0]);
return scalar(@addresses) > 0 ? 1 : 0;
$$;

Alla funktioner som presenteras här är inte beroende av varandra, och då finns det ingen företräde vare sig i dess utveckling eller i dess utplacering. Dessutom, eftersom det kommer att verifieras i förväg, är det inget beroende av deras valideringar.

Så för att exekvera en uppsättning valideringsskript när en commit har utförts i ett kodlager är det nödvändigt att skapa ett byggjobb (nytt objekt) i Jenkins:

Figur 12 – "Freestyle"-projekt för kontinuerlig integration

Detta nya byggjobb ska skapas som "Freestyle"-projekt och i avsnittet "Källkodsförråd" måste arkivets URL och dess referenser definieras (orange ruta):

Figur 13 – Källkodsförråd

I avsnittet "Build Triggers" måste alternativet "GitHub hook trigger for GITScm polling" vara markerat:

Figur 14 – avsnittet "Bygg utlösare"

Slutligen, i avsnittet "Bygg", måste alternativet "Execute Shell" väljas och i kommandorutan skripten som ska utföra valideringen av de utvecklade funktionerna:

Figur 15 – avsnittet "Byggmiljö"

Syftet är att ha ett valideringsskript för varje utvecklad funktion.

Detta Python-skript har en enkel uppsättning satser som anropar dessa procedurer från en databas med några fördefinierade förväntade resultat:

#!/usr/bin/python
import psycopg2

con = psycopg2.connect(database="db_deploy", user="postgres", password="postgres10", host="localhost", port="5432")
cur = con.cursor() 

email_list = { '[email protected]' : True,
                       'tintinmail.com'   :  False,
                       '[email protected]'   : False,
                       'director#mail.com': False,
                       '[email protected]'   : True
                     }
result_msg= "f_IsValidEmail -> OK"

for key in email_list:
  cur.callproc('f_IsValidEmail', (key,))
  row = cur.fetchone()
  if email_list[key]!=row[0]:
    result_msg= "f_IsValidEmail -> Nok"

print result_msg

cur.close()
con.close()

Detta skript kommer att testa den presenterade PLpg/SQL eller plperlu funktioner och den kommer att exekveras efter varje commit i kodförrådet för att undvika regressioner på utvecklingen.

När detta jobbbygge har körts kan loggkörningarna verifieras.

Figur 16 – "Konsolutdata"

Det här alternativet presenterar den slutliga statusen:FRAMGÅNG eller FEL, arbetsytan, de körda filerna/skriptet, de skapade temporära filerna och felmeddelandena (för de misslyckade)!

Slutsats

Sammanfattningsvis är Jenkins känt som ett utmärkt verktyg för kontinuerlig integration (CI) och kontinuerlig leverans (CD), men det kan användas för olika funktioner som,

  • Schemalägga uppgifter
  • Körning av skript
  • Övervaka processer

För alla dessa syften på varje exekvering (Bygg på Jenkins vokabulär) kan det analyseras loggarna och förfluten tid.

På grund av ett stort antal tillgängliga plugins kan det undvika vissa utvecklingar med ett specifikt syfte, förmodligen finns det ett plugin som gör precis vad du letar efter, det är bara att söka i uppdateringscentret eller Hantera Jenkins>>Hantera plugins inuti webbapplikationen.


  1. Exempel på APEX_ZIP

  2. Anslut till fjärr MySQL-server med SSL från PHP

  3. Bestäm rankning baserat på flera kolumner i MySQL

  4. fe_sendauth:inget lösenord tillhandahålls