<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>An introduction to gitops :: Flywheel Data Labs - Workshops</title>
    <link>http://localhost:8080/gitops_intro/index.html</link>
    <description>Description The first 15 minutes of the workshop are slides which provide a foundational backgroun on GitOps and what the technology addresses. The labs consist of doing things like deploying GitOps configuration files to generate the same infrastructure every time it’s deployed, perform and address automatic security scans of your infrastructure, and deploy a server to the cloud.</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 05 May 2020 13:15:09 -0400</lastBuildDate>
    <atom:link href="http://localhost:8080/gitops_intro/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Welcome to the Flywheel Data Lab</title>
      <link>http://localhost:8080/gitops_intro/1.welcome/index.html</link>
      <pubDate>Tue, 05 May 2020 13:15:09 -0400</pubDate>
      <guid>http://localhost:8080/gitops_intro/1.welcome/index.html</guid>
      <description>In this lab we’ll get connected to the lab environment. This is typically the hardest part of the workshop, if we can make it through this then it’s all smooth sailing!&#xA;How it works The lab is in a private enclave which is not directly accessible over the internet. Workshop attendees are able to connect to specific services using ZScaler Browser Access with access controlled by Azure Active Directory.</description>
    </item>
    <item>
      <title>CI/CD Runners</title>
      <link>http://localhost:8080/gitops_intro/a1.workers/index.html</link>
      <pubDate>Tue, 05 May 2020 13:15:09 -0400</pubDate>
      <guid>http://localhost:8080/gitops_intro/a1.workers/index.html</guid>
      <description>In this lab we’re going to deploy a new runner and configure our project to use that runner. Runners can be hosted on bare metal, inside of VMs, or on kubernetes. In this case we’re going to use a kubernetes operator to manage the deployment and configuration of our runner.&#xA;Key Terms Runner - executes jobs in a CI/CD pipeline Operator - a convenient way to deploy and manage resources on kubernetes</description>
    </item>
    <item>
      <title>Deploying with GitOps</title>
      <link>http://localhost:8080/gitops_intro/2.deploy/index.html</link>
      <pubDate>Tue, 05 May 2020 13:15:09 -0400</pubDate>
      <guid>http://localhost:8080/gitops_intro/2.deploy/index.html</guid>
      <description>In this lab we’ll use GitLab CI/CD to deploy our webserver and then we’ll connect to it. We’ll explore how a CI/CD pipeline can be used to build deployment plans, run security scans, and manage the operations or live infrastructure.&#xA;Key Terms CI/CD Pipeline - A series of automated steps which run whenever changes are made to code</description>
    </item>
    <item>
      <title>Making updates</title>
      <link>http://localhost:8080/gitops_intro/3.change/index.html</link>
      <pubDate>Tue, 05 May 2020 13:15:09 -0400</pubDate>
      <guid>http://localhost:8080/gitops_intro/3.change/index.html</guid>
      <description>In this lab we’ll run through a typical infrastructure maintenance process wearing a variety of hats. Specifically we’ll triage a vulnerability found by our security scans, create and assign a ticket to track resolution of the issue, and update our deployment in order to actually fix the problem. Finally we’ll use our CI/CD pipeline to automatically run new scans and deploy our updated infrastructure.&#xA;Key Terms Vulnerability - A weakness in system configuration that could be exploited Issue - A convenient way to document and track a software request Commit - Save a code change to our source control repository</description>
    </item>
    <item>
      <title>Appendix: Configuring Builds</title>
      <link>http://localhost:8080/gitops_intro/a2.builds/index.html</link>
      <pubDate>Tue, 05 May 2020 13:15:09 -0400</pubDate>
      <guid>http://localhost:8080/gitops_intro/a2.builds/index.html</guid>
      <description>Configuring terraform providers via environment variables It is typical for terraform providers to enable configuration through environment variables. The full set of environment variables that are evaluated and how they are used it usually documented in the provider docs, for example look at the athentication section of the kubernetes provider documentation.&#xA;Gitlab allowsenvironment variables to be configured for CI/CD pipelines at every level in the project hierarchy. Environment variables are inherited in the following order:</description>
    </item>
  </channel>
</rss>