Tag Archive for: DevOps

Why using Infrastructure as Code for developing Cloud-based Data Warehouse Systems?

September 20, 2023/in Cloud, Data Engineering, Infrastructure as Code, Main Category, Tutorial/by Benjamin Aunkofer

In the contemporary age of Big Data, Data Warehouse Systems and Data Science Analytics Infrastructures have become an essential component for organizations to store, analyze, and make data-driven decisions. With the evolution of cloud computing, many organizations are now migrating their Data Warehouse Systems to the cloud for better scalability, flexibility, and cost-efficiency. Infrastructure as Code (IaC) can be a game-changer in this scenario. By automating the provisioning and management of cloud resources through code, IaC brings a host of advantages to the development and maintenance of Data Warehouse Systems in the cloud.

So why using IaC for Cloud Data Infrastructures?

Of course you – as a human user – can always login into the admin portal of any cloud provider and manually get your resources like SQL databases, ETL tools, Virtual Networks and tools like Synapse, snowflake, BigQuery or Databrikcs in place by clicking on the right buttons….. But here is why you should better follow the idea of having your code explaining which resources are in what order in place in your cloud:

Version Control for your Cloud Infrastructure

One of the primary advantages of using IaC is version control for your Data Warehouse – or Data Lakehouse – Architecture. Whether you’re using Redshift, Snowflake, or any other cloud-based data warehouse solutions, you can codify your architecture settings, allowing you to track changes over time. This ensures a reliable and consistent development environment and makes it easier to identify issues, rollback updates, or replicate the architecture for other projects.

Scalability Tailored for Data Needs

Data Warehouse Systems often require to scale quickly to handle larger datasets or more queries. Traditional manual scaling methods are cumbersome and slow. IaC allows for efficient auto-scaling based on real-time needs. You can write scripts to automatically provision or de-provision resources depending on your data workloads, making your data warehouse highly adaptive to your organization’s changing requirements.

Cost-Efficiency in Resource Allocation

Cloud resources are priced based on usage, so efficient allocation is crucial for managing costs. IaC enables precise control over cloud resources, allowing you to turn them off when not in use or allocate more resources during peak times. For Data Warehouse Systems that often require powerful (and expensive) computing resources, this level of control can translate into significant cost savings.

Streamlined Collaboration Among Teams

Data Warehouse Systems in the cloud often involve cross-functional teams — data engineers, data scientists, and system administrators. IaC allows these teams to collaborate more effectively. Everyone works with the same infrastructure configurations, reducing discrepancies between development, staging, and production environments. This ensures that the data models and queries developed by data professionals are consistent with the underlying infrastructure.

Enhanced Security and Compliance

Data Warehouses often store sensitive information, making security a paramount concern. IaC allows security configurations to be codified and automated, ensuring that every new resource or service deployed complies with organizational and regulatory guidelines. This proactive security approach is particularly beneficial for industries that have to adhere to strict compliance rules like HIPAA or GDPR.

Reliable Environment for Data Operations

Manual configurations are prone to human error, which can compromise the reliability of a Data Warehouse System. IaC mitigates this risk by automating repetitive tasks, ensuring that the infrastructure is consistently provisioned. This brings reliability to data ETL (Extract, Transform, Load) processes, query performances, and other critical data operations.

Documentation and Disaster Recovery Made Easy

Data is the lifeblood of any organization, and losing it can be catastrophic. IaC allows for swift disaster recovery by codifying the entire infrastructure. If a disaster occurs, the infrastructure can be quickly recreated, reducing downtime and data loss.

Most common IaC solutions

The most common tools for creating Cloud Infrastructure as Code are probably Terraform and Pulumi. However, IaC solutions can be very different in their concepts. For example: While Terraform is a pure declarative configuration language that just describes how the infrastructure will look like (execution then by the Terraform-supporting Cloud Provider), Pulumi on the other hand will execute the deployment by a programming language iteratively deploying the wished cloud resources (e.g. using for loops in Python). While executing Pulumi in any supported programming language like Python or C#, Pulumi generates declarative Infrastructure build plans for the Cloud. Any IaC solution is declaring how the infrastrcture looks like.

Terraform

Terraform is one of the most widely used Infrastructure as Code (IaC) tools, developed by HashiCorp. It enables users to define and provision a data center infrastructure using a declarative configuration language known as HashiCorp Configuration Language (HCL).

The following Terraform script will create an Azure Resource Group, a SQL Server, and a SQL Database. It will also output the fully qualified domain name (FQDN) of the SQL Server, which you can use to connect to the database:

provider "azurerm" {

features {}

}

resource "azurerm_resource_group" "example" {

name = "example-resources"

location = "East US"

}

resource "azurerm_sql_server" "example" {

name = "example-sqlserver"

resource_group_name = azurerm_resource_group.example.name

location = azurerm_resource_group.example.location

version = "12.0"

administrator_login = "adminUser"

administrator_login_password = "adminPassword1234!"

}

resource "azurerm_sql_database" "example" {

name = "example-sqldb"

resource_group_name = azurerm_resource_group.example.name

server_name = azurerm_sql_server.example.name

location = azurerm_resource_group.example.location

edition = "Basic"

}

output "sql_server_fqdn" {

value = azurerm_sql_server.example.fully_qualified_domain_name

}

The HCL code needs to be placed into the Terrafirm main.tf file. Of course, Terraform and the Azure CLI needs to be installed before.

Pulumi

Pulumi is a modern Infrastructure as Code (IaC) tool that sets itself apart by allowing infrastructure to be defined using general-purpose programming languages like Python, TypeScript, Go, and C#.

Example of a Pulumi Python script creating a SQL Database on Microsoft Azure Cloud:

import * as pulumi from "@pulumi/pulumi";

import * as azure from "@pulumi/azure";

// Create an Azure Resource Group

const resourceGroup = new azure.core.ResourceGroup("myResourceGroup", {

location: "EastUS",

});

// Create an Azure SQL Server

const sqlServer = new azure.sql.SqlServer("mySqlServer", {

resourceGroupName: resourceGroup.name,

location: resourceGroup.location,

version: "12.0",

administratorLogin: "adminUser",

administratorLoginPassword: "adminPassword1234!",

});

// Create an Azure SQL Database on the SQL Server

const sqlDatabase = new azure.sql.Database("mySqlDatabase", {

resourceGroupName: resourceGroup.name,

serverName: sqlServer.name,

location: resourceGroup.location,

edition: "Basic",

});

// Export connection string for the SQL Database

export const sqlConnectionString = pulumi.all([sqlServer.name, resourceGroup.name, sqlDatabase.name]).apply(([serverName, rgName, dbName]) => {

return `Server=tcp:${serverName}.database.windows.net;initial catalog=${dbName};user ID=adminUser;password=adminPassword1234!;Min Pool Size=0;Max Pool Size=30;Persist Security Info=true;`;

});

Running the script will need the installation of Python, Pulumi and the Azure CLI.

Cloud Provider specific IaC Solutions

Cloud providers might come up with their own IaC solutions, here are the probably most common ones:

Microsoft Azure Bicep is an open-source domain-specific language (DSL) developed by Microsoft, aimed at simplifying the process of deploying Azure resources. It serves as a declarative alternative to JSON for writing Azure Resource Manager (ARM) templates. Bicep compiles down to ARM templates, offering a more concise syntax and easier tooling while leveraging the proven, underlying ARM deployment engine.

AWS CloudFormation is a service offered by Amazon Web Services (AWS) that allows you to define cloud infrastructure in JSON or YAML templates.

Google Cloud Deployment Manager is quite similar to AWS CloudFormation but tailored for Google Cloud Platform (GCP), it allows you to define and deploy resources using YAML or Python templates.

IaC Tools for Server Configuration

There are many other IaC solutions and some of them are more focused on configuration of servers. In common they offer software provisioning as well and a lot detailing in regards to micro-configuration of single applications running on the server.

The most common IaC software for Server Configuration might be Ansible, a YAML-based configuration management tool that uses an agentless architecture. It’s easy to set up and widely used for automating tasks like software provisioning and configuration management. Puppet, Chef and SaltStack are further alternatives and master-agent architecture-based.

Conclusion

Infrastructure as Code significantly enhances the development and maintenance of Cloud-based Data Infrastructures. From versioning your warehouse architecture and scaling resources according to real-time data needs, to facilitating team collaboration and ensuring security compliance, IaC serves as a foundational technology that brings agility, reliability, and cost-efficiency. As organizations continue to realize the importance of data-driven decision-making, leveraging IaC for cloud-based Data Warehouse Systems will likely become a best practice in data engineering and infrastructure management.

The Cloud or Hybrid Cloud – Pros & Cons

December 20, 2022/in Cloud, Insights, Main Category/by Shannon Flynn

Big data and artificial intelligence (AI) are some of today’s most disruptive technologies, and both rely on data storage. How organizations store and manage their digital information has a considerable impact on these tools’ efficacy. One increasingly popular solution is the hybrid cloud.

Cloud computing has become the norm across many organizations as the on-premise solutions struggle to meet modern demands for uptime and scalability. Within that movement, hybrid cloud setups have gained momentum, with 80% of cloud users taking this approach in 2022. Businesses noticing that trend and considering joining should carefully weigh the hybrid cloud’s pros and cons. Here’s a closer look.

The Cloud

To understand the advantages and disadvantages of hybrid cloud setups, organizations must contrast them against conventional cloud systems. These fall into two categories: public, where multiple clients share servers and resources, and private, where a single party uses dedicated cloud infrastructure. In either case, using a single cloud presents unique opportunities and challenges.

Advantages of the Cloud

The most prominent advantage of traditional cloud setups is their affordability. Because both public and private clouds entirely remove the need for on-premise infrastructure, users pay only for what they need. Considering how 31% of users unsatisfied with their network infrastructure cite insufficient budgets as the leading reason, that can be an important advantage.

The conventional cloud also offers high scalability thanks to its reduced hardware needs. It can also help prevent user errors like misconfiguration because third-party vendors manage much of the management side. Avoiding those mistakes makes it easier to use tools like big data and AI to their full potential.

Disadvantages of the Cloud

While outsourcing management and security workloads can be an advantage in some cases, it comes with risks, too. Most notably, single-cloud or single-type multi-cloud users must give up control and visibility. That poses functionality and regulatory concerns when using these services to train AI models or analyze big data.

Storing an entire organization’s data in just one system also makes it harder to implement a reliable backup system to prevent data loss in a breach. That may be too risky in a world where 96% of IT decision-makers have experienced at least one outage in the last three years.

Hybrid Cloud

The hybrid cloud combines public and private clouds so users can experience some of the benefits of both. In many instances, it also combines on-premise and cloud environments, letting businesses use both in a cohesive data ecosystem. Here’s a closer look at the hybrid cloud’s pros and cons.

Advantages of Hybrid Cloud

One of the biggest advantages of hybrid cloud setups is flexibility. Businesses can distribute workloads across public, private and on-premise infrastructure to maximize performance with different processes. That control and adaptability also let organizations use different systems for different data sets to meet the unique security needs of each.

While hybrid environments may be less affordable than traditional clouds because of their on-premise parts, they offer more cost-efficiency than purely on-prem solutions. Having multiple data storage technologies provides more disaster recovery options. With 75% of small businesses being unable to recover from a ransomware attack, that’s hard to ignore.

Hybrid cloud systems are also ideal for companies transitioning to the cloud from purely on-premise solutions. The mixture of both sides enables an easier, smoother and less costly shift than moving everything simultaneously.

Disadvantages of Hybrid Cloud

By contrast, the most prominent disadvantage of hybrid cloud setups is their complexity. Creating a system that works efficiently between public, private and on-prem setups is challenging, making these systems error-prone and difficult to manage. Misconfigurations are the biggest threat to cloud security, so that complexity can limit big data and AI’s safety.

Finding compatible public and private clouds to work with each other and on-prem infrastructure can also pose a challenge. Vendor lock-in could limit businesses’ options in this regard. Even when they get things working, they may lack transparency, making it difficult to engage in effective big data analytics.

Which Is the Best Option?

Given the advantages and disadvantages of hybrid cloud setups and their conventional counterparts, it’s clear that no single one emerges as the optimal solution for every situation. Instead, which is best depends on an organization’s specific needs.

The hybrid cloud is ideal for companies facing multiple security, regulatory or performance needs. If the business has varying data sets that must meet different regulations, some information that’s far more sensitive than others or has highly diverse workflows, they need the hybrid cloud’s flexibility and control. Companies that want to move slowly into the cloud may prefer these setups, too.

On the other hand, the conventional cloud is best for companies with tighter budgets, limited IT resources or a higher need for scalability. Smaller businesses with an aggressive digitization timeline, for example, may prefer a public multi-cloud setup over a hybrid solution.

Find the Optimal Data Storage Technology

To make the most of AI and big data, organizations must consider where they store the related data. For some companies, the hybrid cloud is the ideal solution, while for others, a more conventional setup is best. Making the right decision begins with understanding what each has to offer.

Google Cloud run with Infrastructure by Code using Terraform

Google Cloud Run – Tutorial

November 8, 2022/in Cloud, Data Science Hack, DevOps, Infrastructure as Code, Terraform/by Otrek Wilke

Es gibt Gelegenheiten, da ist eine oder mehrere serverlose Funktionen nicht ausreichend, um einen Service darzustellen. Für diese Fälle gibt es auf der Google Cloud Plattform Google Cloud Run. Cloud Run bietet zwei Möglichkeiten Container auszuführen. Services und Jobs. In diesem Beispiel wird ein Google Cloud Run Service mittels Terraform definiert, welcher auf Basis eines Scheduler Jobs regelmäßig aufgerufen wird. Cloud Build wird dazu genutzt den aktuellen Code auf den Service zu veröffentlichen.

Der nachfolgende Quellcode ist in GitHub verfügbar: https://github.com/fingineering/GCPCloudRunDemo

tl;dr

Mittels Terraform können alle notwendigen Komponenten erstellt werden, um einen Cloud Run Services aus einem Github Repository kontinuierlich zu aktualisieren. Als Beispiel wird ein stark vereinfachter Flask Webservice verwendet. Durch den Cloud Scheduler wird dieser Service regelmäßig aufgerufen.

Voraussetzungen

Bevor der Service aufgesetzt werden kann, müssen einige Voraussetzungen erfüllt sein. Es wird ein Google Cloud Project benötigt, sowie ein Github Account. Auf dem Computer, welcher zur Entwicklung verwendet werden soll, müssen Terraform, Google Cloud SDK, git, Docker und Python installiert sein. In diesem Beispiel wird Python verwendet, es ist aber mit jeder Sprache möglich, mit der ein WebServer erstellt werden kann.

Ein Google Cloud Projekt kann bei Google Cloud Plattform erstellt werden. Es wird nur ein Google Account benötigt, Neukunden erhalten ein kostenloses Guthaben von 300€ für 90 Tage.
Wenn noch nicht vorhanden sollte ein kostenloser Github Account auf Github erstellt werden. Das Beispiel kann auch mittels Google Cloud Source Repositories umgesetzt werden. Als Alternative zu Cloud Build kann Github Actions eingesetzt werden.
Terraform, Google Cloud SDK, Docker und Python müssen auf dem verwendeten Computer installiert werden, hierzu empfiehlt sich ein Paketmanager wie Homebrew oder Chocolatey. Linux Nutzer verwenden am besten den in ihrer Distribution mitgelieferten.
Soll nichts installiert werden, dann kann auch die Google Cloud Shell verwendet werden, diese findet sich im in der Cloud Console

APIs die in Google Cloud aktiviert werden müssen

Neben den Voraussetzungen zur Software müssen auf der Google Cloud Plattform einige APIs aktiviert werden:

Cloud Run API
Cloud Build API
Artifact Registry API
Cloud Scheduler API
Cloud Logging API
Identity and Access Management API

Die Cloud Run API wird benötigt um einen Cloud Run Service zu erstellen, die Artifact Registry wird benötigt, um die Container Abbilder zu speichern. Die Cloud Build API und die Identity and Access Management API werden benötigt, um eine CI/CD Pipeline zu implementieren. Cloud Scheduler wird in diesem Beispiel verwendet, um den Service regelmäßig aufzurufen. Da alle Services via Terraform erstellt und verwaltet werden, werden die APIs benötigt.

Infrastruktur

Das Erstellen der Infrastruktur läuft in mehreren Schritten ab, nur wenn App Code und Container bereits vorhanden sind, kann der gesamte Prozess automatisiert werden. Für die Definition der Infrastruktur wird ein Ordner “Infrastructure” erstellt und darin die Dateien main.tf, variables.tfund terraform.tfvars.

mkdir Infrastructure

cd Infrastructure

touch main.tf

touch terraform.tfvars

Insgesamt werden vier Komponenten erstellt, das Artifact Registry Repository, ein Cloud Run Service, ein Cloud Build Trigger und ein Cloud Scheduler Job. Bevor die eigentliche Infrastruktur erzeugt werden kann, müssen einige Service Accounts definiert werden. Ziel ist es, das jedes Asset eine eigene Identität zugewiesen werden kann. Daher werden drei Service Accounts erstellt, für den Run Service, den Build Trigger und den Scheduler Job.

resource "google_service_account" "cloud_run_demo_sa" {

project = var.project_name

account_id = "cloudrundemosa"

description = "Running Cloud Run Scheduled Job to update data in BigQuery under this account"

display_name = "Cloud Run Demo Service Account"

}

# Service account for scheduler to call the function

resource "google_service_account" "cloud_shedule_caller" {

project = var.project_name

account_id = "cloudscheduler"

description = "A service account to run the scheduler under an invoke the cloud run service"

display_name = "Cloud Scheduler Demo User"

}

# Service Account to run the cloud build trigger

resource "google_service_account" "cloud_run_demo_builder" {

project = var.project_name

account_id = "cloudrundemobuilder"

description = "A service account to run the cloud build trigger"

display_name = "Cloud Run Demo Build Trigger"

}

Da der erste Schritt die Einrichtung der Artifact Registry für den Cloud Run Service ist, wird dieser wie folgt hinzugefügt:

resource "google_artifact_registry_repository" "container_demo_repo" {

location = var.location

project = var.project_name

repository_id = var.container_name

description = "Demo docker repository"

format = "DOCKER"

}

// create the url of a container in the registry, by name of container

data "google_container_registry_image" "demo_container" {

name = var.container_name

project = var.project_name

}

Nun kann der erste Schritt zum Aufsetzen der Infrastruktur mittels des Terraform Dreiklangs durchgeführt werden:

# initialize the terraform project

terraform init

# check if everything will go as planned

terraform plan

# create the infrastructure

terraform apply

Die Beispiel Flask Anwendung

Als Beispielanwendung wird hier eine sehr simple Flask Webapp verwendet. Die Webapp beinhaltet eine einzige Route, es wird Hello World bei einem GET Request zurück gegeben und mittels POST kann die Nachricht personalisiert werden. Die Anwendung dient nur der Demonstration, es können fast beliebige Funktionalitäten umgesetzt werden.

Es ist auch nur zwingend notwendig flask oder Python zu verwenden, es kann jede Sprache und jedes Framework eingesetzt werden, welches einen Webserver implementieren kann und auf HTTP Anfragen reagieren kann. Flask selbst ist ein sogenanntes Micro Framework und kann flexibel eingesetzt werden, für mehr Informationen empfiehlt sich z.b. das Flask Mega Tutorial

Im Projektverzeichnis muss ein neuer Ordner App erzeugt werden, in diesem Ordner wird die Python Datei main.py, sowie die requirements.txt Datei erzeugt.

from flask import Flask, request

app = Flask(__name__)

@app.route('/', methods=['GET', 'POST'])

def main():

if request.method == 'POST':

# get some incomming data

data = request.get_json()

# This would be the place where could call your code to run.

# But that wouldn't be a good idea.

# Therefore we create a script package, register the scripts and run

# them all in here

return f"Hello {data['name']}"

return "Hello World"

if __name__ == '__main__':

"""

Creating a very basic debug app. Don't use this in production

"""

app.run(

debug=True,

port=8000,

host="0.0.0.0"

)

Dieser minimale Webservice kann local ausgeführt werden indem ein virtual environment erzeugt und die in requirements.txt spezifizierten Pakete installiert werden.

# create a virtual environment

python -m venv venv

# activate it

source venv/bin/activate

# install required packages

pip install -r requirements.txt

Die App kann nun local ausgeführt werden mittels:

				
				1

						python main.py

Zum Testen kann im Browser die Adresse localhost:8080 aufgerufen werden oder mittels curl ein POST Request an den Service gesendet werden.

				
				1
2
3

						curl -X POST -H "Content-Type: application/json" \
    -d '{"name": "FooBar"}' \
    http://localhost:8080

Der mit flask mitgelieferte Web Server sollte nur zu Entwicklungszwecken verwendet werden, in produktiven Umgebungen kann z.b. gunicorn eingesetzt werden. Gunicorn wird in diesem Beispiel später auch im Container verwendet werden.

				
				1

						gunicorn --bind 0.0.0.0:8080 --workers 1 main:app

Docker Container erstellen, ausführen und deployen

Um einen Service in Cloud Run auszuführen, muss dieser in einem Docker Container vorliegen. Dazu wird zunächst ein Dockerfile im App Ordner erstellt. Diese ist einfach gehalten, es basiert auf einem Python Container, kopiert die Dateien aus dem App Ordner und definiert das Start Kommando für Gunicorn.

In vielen Fällen sind im lokalen Entwicklungsordner Dateien vorhanden die nicht in den Container veröffentlicht werden sollten, damit Dateien explizit aus der Containererzeugung ausgeschlossen werden können kann eine .dockerignore Datei hinzugefügt werden. Diese funktioniert analog der .gitignore Dateien.

Um das Veröffentlichen auf die Artifact Registry zu vereinfachen, kann es eine gute Idee sein dem Namensschema der Registry zu folgen: location—docker.pkg.dev/your-project-id/registryname/containername:latest. Mittels docker build kann das Container Image erstellt werden:

				
				1

						docker build -t LOCATION-docker-pkg.dev/your-project-name/democontainer/democontainer:latest .

Um das erstellt Image local zu testen, kann dieses mittels docker run auch lokal ausgeführt werden. Wichtig ist dabei zu beachten die notwendigen Umgebungsvariablen mit zugeben und den Port zu exponieren.

				
				1

						docker run -e PORT=8080 -p 8080:8080 <image_id>

Werden im Webservice Google Identitäten verwendet, dann müssen Informationen über den zu verwendenden Google Account mitgegeben werden. Wie dies im Detail funktioniert findet sich unter Cloud Run lokal testen.

Den ersten Container manuell deployen

Bevor es möglich ist den Cloud Run Service zu erstellen muss das Container Abbild einmal manuell in die Artifact Registry veröffentlicht werden.

				
				1

						docker push europe-west3-docker.pkg.dev/snappy-nature-350016/democontainer/democontainer:latest

Erstellen und veröffentlichen des Container Abbilds kann auch in einem Kommando erfolgen:

				
				1
2

						docker buildx build -t name_of_image —push -f Dockerfile

Cloud Run Service aufsetzen

Da der initiale Container nun in der Aritfact Registry vorhanden ist, kann der Cloud Run Service daraus erstellt werden. Für den Cloud Run Service wird eine neue Resource im main.tf erstellt.

resource "google_cloud_run_service" "cloud_run_demo" {

project = var.project_name

name = var.RunJobName

location = var.location

template {

spec {

containers {

image = "europe-west3-docker.pkg.dev/${var.project_name}/${var.container_name}/${var.container_name}:latest"

}

traffic {

percent = 100

latest_revision = true

}

# A Schedule to run the job on

resource "google_cloud_scheduler_job" "timer_trigger" {

name = "scheduled-cloud-run-job"

project = var.project_name

description = "Invoke a Cloud Run container on a schedule."

schedule = "*/8 * * * *"

time_zone = "Europe/Berlin"

attempt_deadline = "320s"

retry_config {

retry_count = 2

}

http_target {

http_method = "POST"

uri = google_cloud_run_service.cloud_run_demo.status[0].url

oidc_token {

service_account_email = google_service_account.cloud_shedule_caller.email

}

Dieser Service ist zunächst privat, alle Identitäten die diesen Service aufrufen wollen benötigen die Rolle roles/run.invoker. Da der Cloud Scheduler den Service regelmäßig aufrufen soll, muss die Identität des Schedulers Mitglied der Rolle sein.

				
					
				1
2
3
4
5
6
7
8
9
10
11

						# allow shedule to run the cloud run service
resource "google_cloud_run_service_iam_binding" "invoker" {
  location = var.location
  project  = var.project_name
  service  = google_cloud_run_service.cloud_run_demo.name
  role     = "roles/run.invoker"
  members = [
    "user:${var.service_owner}",
    "serviceAccount:${google_service_account.cloud_shedule_caller.email}"
  ]
}

					

			

Nun kann der Terraform Dreiklang verwendet werden den Service und den Scheduler Job zu erstellen.

Cloud Build Trigger erstellen

Der finale Schritt um ein kontinuierliches deployment des Services zu erreichen ist einen Cloud Build Trigger einzurichten. Der Cloud Build Trigger beobachtet Veränderungen am GitHub Repository und erstellt bei jedem neuen Commit auf dem main branch eine neue Version des Cloud Run Services. Die hier vorgestellte Pipeline beinhaltet nur das Erstellen und Veröffentlichen des Containers. Für eine produktive Implementation ist unbedingt zu empfehlen auch noch ein Testschritt mit einzufügen. Mit dem folgenden Code wird der Trigger mittels Terraform erstellt:

				
					
				1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

						resource "google_cloudbuild_trigger" "demo_cloud_build" {
  name            = "CloudRundDemo"
  project         = var.project_name
  description     = "Triggers a new cloud run image to be build, when new code is published"
  service_account = google_service_account.cloud_run_demo_builder.id
  github {
    owner = "fingineering"
    name  = "GCPCloudRunDemo"
    push {
      branch = "main"
    }
  }
  filename = "cloudbuild.yaml"
 
  substitutions = {
    "_REPO"         = var.container_name
    "_IMAGE_NAME"   = var.container_name
    "_LOCATION"     = var.location
    "_SERVICE_NAME" = google_cloud_run_service.cloud_run_demo.name
  }
}
 
# IAM Binding for Cloud Run
# Allow Cloud Build to edit the cloud run service
resource "google_cloud_run_service_iam_member" "triggerRunServiceDeveloper" {
  location = var.location
  project  = var.project_name
  service  = google_cloud_run_service.cloud_run_demo.name
  role     = "roles/run.admin"
  member   = "serviceAccount:${google_service_account.cloud_run_demo_builder.email}"
}

					

			

Der Cloud Build Trigger nutzt zur Definition des Deployment Processes die Datei cloudbuild.yaml, diese enthält die drei Schritte zum Erstellen des Container Abbilds, Veröffentlichen des Abbilds und Erzeugen einer neuen Version des Cloud Run Services.

				
					
				1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

						steps:
# build step
- name: 'gcr.io/cloud-builders/docker'
  args: [ 'build', '-t', '$_LOCATION-docker.pkg.dev/$PROJECT_ID/$_REPO/$_IMAGE_NAME:latest', './App' ]
# push to artifact registry
- name: 'gcr.io/cloud-builders/docker'
  args: ['push', '$_LOCATION-docker.pkg.dev/$PROJECT_ID/$_REPO/$_IMAGE_NAME:latest']
# Deploy Container to Cloud Run
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
  entrypoint: gcloud
  args: ['run', 'deploy', '$_SERVICE_NAME', '--image', '$_LOCATION-docker.pkg.dev/$PROJECT_ID/$_REPO/$_IMAGE_NAME:latest', '--region', '$_LOCATION']
images:
- '$_LOCATION-docker.pkg.dev/$PROJECT_ID/$_REPO/$_IMAGE_NAME:latest'
options:
  logging: CLOUD_LOGGING_ONLY

					

			

Erstellen des Container Abbilds mittels des Docker build Tools. Das erste Argument ist die Aktion build, das zweite und dritte beziehen sich auf den Tag des Images und das vierte gibt den Ort vor an dem nach dem Dockerfile gesucht wird
Veröffentlichen des Container Images in die Artifact Registry mittels des Cloud Build Docker Tools. Als Argumente werden die Aktion push und das Ziel mitgegeben.
Veröffentlichen der neuen Version des Images im Cloud Run Service mittels des Google Cloud SDK Tools gcloud

Alle drei Schritte nutzen Variablen, um Projektziel, Image Tag und Ort flexibel durch den Build Trigger zu steuern. Diese Variable werden bei der Erstellung des Triggers mit definiert, d.h. dieser finden sich in der Definition des Cloud Build Triggers in der Terraform Datei. Die Variablen werden substitutions genannt, es ist zu beachten, das nutzerdefinierte Variablen mit einem Unterstrich beginnen müssen, nur Systemvariablen, wie die PROJECT_ID.

Das Erstellen des Cloud Build Triggers kann versagen, in diesem Falle sollten die Einstellungen von Cloud Build in der Cloud Console geprüft werden. Die Service Account Berechtigungen für Cloud Run und Service Accounts müssen aktiviert sein, wie im Bild unten.

Service Account Berechtigungen für Cloud Run und Service Accounts

Zusammenfassung

Mit Hilfe von Terraform ist es möglich ein vollständig in Code definierten, kontinuierlich veröffentlichten Google Cloud Run Service zu erstellen. Dazu werden GCP Services verwendet, eine Flask Webapp in einem Container zu verpacken und diesen auf Cloud Run zu veröffentlichen.

Für Fragen erstellt gerne ein Issue oder ihr findet mich auf LinkedIn.

Der Quellcode ist in GitHub verfügbar: https://github.com/fingineering/GCPCloudRunDemo

Die Notwendigkeit von DevOps in Data Science

February 24, 2021/in Data Engineering/by Lea Krause

Datenwissenschaft und maschinelles Lernen werden häufig mit Mathematik, Statistik, Algorithmen und Datenstreitigkeiten in Verbindung gebracht. Während diese Fähigkeiten für den Erfolg der Implementierung von maschinellem Lernen in einem Unternehmen von zentraler Bedeutung sind, gewinnt eine Funktion zunehmend an Bedeutung – DevOps for Data Science. DevOps umfasst die Bereitstellung der Infrastruktur, das Konfigurationsmanagement, die kontinuierliche Integration und Bereitstellung, das Testen und die Überwachung. Die DevOps Consulting – Teams haben eng mit den Entwicklungsteams zusammengearbeitet, um den Lebenszyklus von Anwendungen effektiv zu verwalten.

Data Science bringt DevOps zusätzliche Verantwortung. Data Engineering, eine Nischendomäne, die sich mit komplexen Pipelines befasst, die die Daten transformieren, erfordert eine enge Zusammenarbeit von Data Science-Teams mit DevOps. Datenwissenschaftler untersuchen transformierte Daten, um Erkenntnisse und Korrelationen zu finden. Von den DevOps-Teams wird erwartet, dass sie Datenwissenschaftler unterstützen, indem sie Umgebungen für die Datenexploration und -visualisierung erstellen.

Das Erstellen von Modellen für maschinelles Lernen unterscheidet sich grundlegend von der herkömmlichen Anwendungsentwicklung. Die Entwicklung ist nicht nur iterativ, sondern auch heterogen. Datenwissenschaftler und -entwickler verwenden eine Vielzahl von Sprachen, Bibliotheken, Toolkits und Entwicklungsumgebungen, um Modelle für maschinelles Lernen zu entwickeln. Beliebte Sprachen für die Entwicklung des maschinellen Lernens wie Python, R und Julia werden in Entwicklungsumgebungen verwendet, die auf Jupyter Notebooks, PyCharm, Visual Studio Code, RStudio und Juno basieren. Diese Umgebungen müssen Datenwissenschaftlern und Entwicklern zur Verfügung stehen, die ML-Probleme lösen.

Maschinelles Lernen und Deep Learning erfordern eine massive Computerinfrastruktur, die auf leistungsstarken CPUs und GPUs ausgeführt wird. Frameworks wie TensorFlow, Caffe, Apache MXNet und Microsoft CNTK nutzen die GPUs, um komplexe Berechnungen für das Training von ML-Modellen durchzuführen. Das Bereitstellen, Konfigurieren, Skalieren und Verwalten dieser Cluster ist eine typische DevOps-Funktion. DevOps-Teams müssen möglicherweise Skripts erstellen, um die Bereitstellung und Konfiguration der Infrastruktur für eine Vielzahl von Umgebungen zu automatisieren.

Ähnlich wie bei der modernen Anwendungsentwicklung ist die Entwicklung des maschinellen Lernens iterativ.

Wenn ein vollständig trainiertes ML-Modell verfügbar ist, wird von DevOps-Teams erwartet, dass sie das Modell in einer skalierbaren Umgebung hosten, beispielsweise mit Microsoft Azure und die dazugehörige DevOps-Lösung. Sie können Orchestrierungs-Engines wie Apache Mesos oder Kubernetes nutzen, um die Modellbereitstellung zu skalieren.

DevOps-Teams nutzen Container für die Bereitstellung von Entwicklungsumgebungen, Datenverarbeitungs-Pipelines, Schulungsinfrastrukturen und Modellbereitstellungsumgebungen. Neue Technologien wie Kubeflow und MlFlow konzentrieren sich darauf, DevOps-Teams in die Lage zu versetzen, die neuen Herausforderungen im Umgang mit der ML-Infrastruktur zu bewältigen.

Maschinelles Lernen verleiht DevOps eine neue Dimension. Zusammen mit den Entwicklern müssen die Betreiber mit Datenwissenschaftlern und Dateningenieuren zusammenarbeiten, um Unternehmen zu unterstützen, die das ML-Paradigma annehmen.

Tag Archive for: DevOps

Nothing Found

Sorry, no posts matched your criteria

Tag Archive for: DevOps

Why using Infrastructure as Code for developing Cloud-based Data Warehouse Systems?

So why using IaC for Cloud Data Infrastructures?

Version Control for your Cloud Infrastructure

Scalability Tailored for Data Needs

Cost-Efficiency in Resource Allocation

Streamlined Collaboration Among Teams

Enhanced Security and Compliance

Reliable Environment for Data Operations

Documentation and Disaster Recovery Made Easy

Most common IaC solutions

Terraform

Pulumi

Cloud Provider specific IaC Solutions

IaC Tools for Server Configuration

Other types of IaC Solutions

Conclusion

Die Notwendigkeit von DevOps in Data Science

Tag Archive for: DevOps

Nothing Found

Interesting links

Pages

Categories

Archive