DEV Community: Melissa Sussmann

Announcing Relay's General Availability Launch

Melissa Sussmann — Tue, 06 Apr 2021 00:00:00 +0000

Today we’re proud to announce the general availability of Relay, a cloud-native workflow automation platform. We launched our public beta of Relay last June, and we’re now officially out of beta and open for business! We’ve been pretty busy during the beta period - early users have executed thousands of workflows, processed tons of events, and given us incredibly helpful feedback.

We believe there is tremendous demand for a new kind of low-code, responsive automation product because:

The cloud has radically changed how we build and operate systems.
Lower-level infrastructure components are, for the most part, good enough at the problems they are intended to solve.
Complexity has moved up the stack, beyond configuring operating systems and into how we tie services, APIs, and distributed systems together.
DevOps teams encompass a wide range of skills, and it’s important to the business that their tiny number of automation specialists democratize their knowledge across the organization.

Thus, how we automate across our infrastructure must change accordingly.

We’ve heard over and over from our users how their quotidian tasks are deceptively tricky and involve sequencing lots of actions across all manner of different services. Going through these tasks manually introduces room for error, even when they’re properly documented. Between responding to service-down incidents, rolling back failed deployments, and securing cloud resources… the struggle is real.

Solving these problems involves gluing together a patchwork of existing scripts, bespoke in-house APIs, and 3rd-party services to get anything done. This emerging need for better orchestration is why Relay is built around event-driven workflows. What does that mean, exactly?

Modern service architectures generate all kinds of events — mostly noise, but with important signals intermixed — and the ability to understand and respond to those events automatically is key. YAML-based workflows provide a readable, reusable abstraction that the whole team can comprehend and iterate on. They’re well-suited for assembling individual automation “steps” into an end-to-end solution. So, combining workflows and events leads to truly responsive automation that can cover the full continuum of scenarios ops folks are regularly faced with, at the velocity they need.

Powerful abstractions like events and workflows are great, but not if they come at the expense of accessibility or if they present users with more of a learning cliff than a gentle curve. One thing we learned during the beta was that users wanted the best of both worlds: a simple workflow authoring experience that doesn’t require much coding, but that is also harmonious with their overall infrastructure-as-code approach. This is why Relay takes a low-code approach to workflow authoring. We’ve spent a lot of time making that experience quick and easy, but all the while changes are bi-directionally synced to human-friendly code.

It’s been wonderful seeing the automation problems that our users have solved with Relay. The major themes that have arisen are:

Self-healing infrastructure - using Relay to add intelligence to existing automation tools, driving them in response to high-signal events, and integrating them into higher-level, auto-remediation workflows, e.g. combining Relay with Puppet Enterprise or doing automated rollback of a complex deployment.
Compliance - using Relay to continually verify the security posture of key cloud resources by receiving infrastructure events and then applying the right compliance policies. This is such an important issue for users that we plan to do a lot more on this front. Stay tuned for more on this soon!
Incident response - using Relay to enrich alert data, automate incident communications, and trigger auto-remediation workflows, e.g. our partnerships with PagerDuty, DataDog, and Splunk.

Case Study

One of our current customers, Bryxx NV, is a Belgium-based managed service provider that is consolidating its cloud automation stack onto Relay. Bryxx manages its customers’ multi-cloud infrastructure and collects telemetry in Grafana. We worked together to build a Grafana integration for Relay with two parts: Relay receives threshold alerts from Grafana when additional capacity is needed. After running workflows that handle the scale-up, Relay posts an annotation back into Grafana, so there’s a record of the workflow run overlaid on the dashboard, providing an audit trail and visual record of the changes.

Before using Relay, Bryxx had parts of these operations automated but still had to manually coordinate and orchestrate the changes. Now, Bryxx’s DevOps Architect Dries Dams says, “Relay helps us connect all the dots, achieving true self-healing systems on cloud-native platforms. The ease with which we can create new workflows saves us countless hours of developing custom scripts leaving more time for our engineers to help our customers grow their business.”

Next steps

The next step, and the best step, is to try it out (for free)! There are two additional tiers that complement the free Community tier:

Team : ($20 user/month) For small to mid-sized teams, this tier provides access to up to 30 users, 500 active workflows, Role-Based Access Control (RBAC), and Single Sign-On (SSO).
Enterprise : For large organizations with on-prem needs, this tier provides up to 5,000 active workflows and up to 5,000 users. It also provides RBAC and SSO and on-prem connectivity with Puppet Enterprise, Puppet’s flagship product. Contact sales for pricing.

If you’d like to learn more about Relay:

How to get involved to extend Relay to better meet your needs and become part of the Relay community.
The documentation site introduces Relay, its usage, core concepts, and extension points.
Join the Puppet community Slack - come linger in the #relay channel! The more the merrier.

Thanks, and happy automating!

Happy Hacktoberfest

Melissa Sussmann — Tue, 27 Oct 2020 00:00:00 +0000

Happy Halloween! ‘Tis the spooky season and this year, we are kicking off a Hacktoberfest challenge just in time for Halloween. All you have to do for this Hacktoberfest challenge is run a workflow and fill out a brief survey about Relay.

In return we’ll send you a great Relay-themed t-shirt, inspired by the upcoming game, Cyberpunk 2077. The first 75 respondents will get a free t-shirt. We can confidently promise it won’t be as delayed as Cyberpunk. Sadly, we can only offer this shirt to those people living in the continental USA.

As you may already know, Relay (by Puppet) is an event-driven automation platform that pulls together all the tools and technologies DevOps engineers need to effectively manage their environment. It works by listening to signals from DevOps tools and apps people already use and then triggers workflows to orchestrate any required downstream service.

Here’s what you need to do to get your free t-shirt:

1. Sign up or login to Relay

If you don’t already have an account you can create one for free.

2. Run this workflow!

Install the workflow and then click the run button.

3. Click the “View Logs” button

In the logs you will find the URL for the survey. Head there to get started.

4. Fill out the survey

This should only take a few minutes.

5. We’ll send you a t-shirt!

Thanks for making our product really special and please see this as a thank you for your continued support.

How to Reduce MTTR with PagerDuty and Relay

Melissa Sussmann — Mon, 21 Sep 2020 00:00:00 +0000

DevOps and SRE teams are under intense pressure to reduce the Mean Time to Recovery (MTTR) in resolving incidents. With the proliferation of cloud services and the increasing complexity of DevOps toolchains, engineers today need to not only learn how to use these services but also troubleshoot them when an incident is raised at 2 AM. Incident response is still manual today – cobbling together runbooks and ad hoc scripts and orchestrating people to respond. This “digital duct tape” approach results in what we call the “DevOps Dumping Ground”, which ultimately extends MTTR.

How PagerDuty & Relay Work Together

PagerDuty is the industry-leading incident management platform that provides reliable notifications, automatic escalations, on-call scheduling, and other functionality to help teams detect and fix infrastructure problems quickly.

Relay by Puppet is an event-driven automation platform that pulls together all the tools and technologies DevOps engineers need to effectively manage a cloud environment. Unlike many existing workflow automation tools, Relay can intelligently respond to external signals by combining event-based triggers with a powerful workflow engine in a single platform.

The latest integration between Relay and PagerDuty eliminates the “digital duct tape” by creating reusable, event-driven workflows to close the loop on incidents faster through Relay’s event-based automation approach. PagerDuty users can now:

Enrich alert data : Using the new Change Events launched at PagerDuty Summit, Relay enhances alerts with diagnostic information to speed time-to-resolution by presenting more context around the alert.
Automate incident communication : Whether it’s creating a Slack room, updating a Jira ticket, or notifying team members, Relay ensures that communication is timely and updated.
Trigger Auto-Remediation Workflows : Raising PagerDuty incidents can initiate Relay workflow runs to fix troubleshoot & remediate common problems securely and quickly.

Example: How to Automate Incident Communication Plans

A key way to reduce MTTR is to formalize an incident communication plan. Making sure that teams have a robust plan for understanding roles and opening communication channels is key to reducing incident response time. Relay can automate this workflow for you by contacting the on-call engineer with a message detailing content from the incident.

Relay uses “triggers” and “steps” to automate a set of actions. Steps are reusable, modular, and composable – things like getting a user’s info, sending Slack and Twilio messages, and using the PagerDuty Event API to provide more information on an incident. “Triggers” are based on cloud events, git events, monitoring alerts, tickets, and incidents. In the example below, we see how a PagerDuty incident triggers the following incident response workflow utilizing the steps mentioned.

When a new PagerDuty incident is raised, Relay looks up the on-call person’s email address, identifies that user in Jira and Slack, and creates a Jira ticket for the production incident. Relay then creates a Slack room as a production incident command center, invites the on-call in, along with the pertinent engineering manager, and sets the topic of the room with a link to the Jira ticket that has been created. Finally, it sends a message to the Slack room and posts a note with the expectations of how a production incident policy should be followed.

Using PagerDuty’s exciting new Change Events, Relay elaborates on content from the incident with enriched alert data. This enables the individual on call to respond to the incident quickly, with less toil required for ticket creation and communication on what triggered the workflow.

Try out this workflow here.

Customize your Incident Response

There are several starter workflows available for PagerDuty users, which you can find on their integration page. You can use these workflows to create an issue in Jira, send a message to slack, and send a Twillo SMS automatically when a PagerDuty incident is triggered.

Everyone’s workflow is a little different, so Relay workflows are customizable for use cases. Relay provides contextual help within its sidebar. This feature lets you browse the library of integrations and steps to make it easy to customize your workflow.

Sign Up for Relay!

Use Relay with PagerDuty to reduce your incident response time and improve observability. Reducing your mean time to resolution (MTTR) is key to successful DevOps management and enabling event-driven automation will mean that your incident response time is much shorter. Relay makes this easier by using workflows that fix more common and well-understood problems that teams have already identified. To learn more about Relay, visit our site at relay.sh and sign up for our free beta!

Take Control of your DevOps Dumping Ground with Relay!

Melissa Sussmann — Thu, 30 Jul 2020 00:00:00 +0000

click here for the webinar

Learn How to Use Relay to Clean up Your DevOps Dumping Ground

As the automation surface area grows to accommodate hundreds of interconnected APIs on the cloud, developers are using their own, home-grown “digital duct tape” to manage a growing “DevOps dumping ground”. For a lot of organizations, home-grown glue logic is inconsistent, not repeatable, and expensive to maintain hundreds of event-based workflows and thousands of combinations. We believe that the answer lies in automation workflows. In particular, workflows-as-code that can be triggered by events. We want to replace engineers’ home-grown digital duct tape with reusable, event-driven workflows.

In an effort to deal with ad-hoc deployments and devops infrastructure CI/CD management, many devs try to create their own one-off automation tools or integration hubs, usually per team or per project. Examples include:

Using Lambda and writing functions for EC2 management tasks
Running scheduled jobs for EBS cleanup
Repurposing a CI/CD tool like Jenkins for incident response workflows

But this “dumping ground” current approach is Inefficient, expensive and risky

Inefficient because work is done as one offs that last forever, no reusability or repeatability
Expensive because spending time building tools and integrations isn’t directly delivering customer value
Risky because sidestepping governance to get stuff done can lead to exposure and failures

This webinar presentation from Melissa Sussmann and Kenaz Kwa at Puppet gives viewers a peek into the beta version of Relay, a product for managing containerized apps. This presentation goes over what the team has learned in the process of working on Relay, the underpinnings of the product, and demonstrates a few example workflows to help you save time and money.

What is Knative? Intro to Canary and Blue-Green Deployments with Dashboards (no YAML)

Melissa Sussmann — Tue, 28 Apr 2020 00:00:00 +0000

This article is a continuation of the “What is Knative” series, by Dimitri Tischenko. For part 1, please follow this link. In part 2 of this series, we will review canary and blue-green deployments and dashboards while using no YAML!

If we raise the load on our service, Knative will autoscale it even further. Exactly how Knative should autoscale can be configured globally or per service.

To load our helloworld service we are first going to modify its configuration. By default, a service is configured to handle 100 concurrent requests. We will reduce it to 10 to be able to show the effects of autoscaling.

> kn service update helloworld --concurrency-limit=10

Configurations, Routes, Revisions

To understand what happens now, we need to take a look at other Knative objects:

> kubectl get crd|grep serving.knative
configurations.serving.knative.dev 2020–04–02T12:13:20Z
revisions.serving.knative.dev 2020–04–02T12:13:21Z
routes.serving.knative.dev 2020–04–02T12:13:21Z
services.serving.knative.dev 2020–04–02T12:13:22Z

As we can see, there are 4 Custom Resource Definitions inside our K8S cluster which are specific to Knative Serving: configurations, revisions, routes and services. Because Kubernetes has a native resource type “service”, the Knative one is called “kservice” or “ksvc”.

A Knative Service represents the microservice, the app which we just deployed. The service has a route which defines under which url it is accessible. It also has a configuration — the combination of code and settings — which can be versioned in revisions.

> kn service describe helloworld
Name: helloworld
Namespace: default
Age: 19m
URL: [http://helloworld.default.127.127.127.127.xip.io](http://helloworld.default.127.127.127.127.xip.io)

Revisions:
  100% @latest (helloworld-pflmj-2) [2] (1m)
    Image: gcr.io/knative-samples/helloworld-go (pinned to 5ea96b)

Conditions:
  OK TYPE AGE REASON
  ++ Ready 1m
  ++ ConfigurationsReady 1m
  ++ RoutesReady 1m

We see under Revisions that 100% of the traffic goes to the revision helloworld-pflmj-2 a.k.a. @latest, and we also see which image version is used in that revision.

Let’s check out our revisions:

> kn revision list
NAME SERVICE TRAFFIC TAGS GENERATION AGE CONDITIONS READY REASON
helloworld-pflmj-2 helloworld 100% 2 115s 3 OK / 4 True
helloworld-snxyt-1 helloworld 1 20m 3 OK / 4 True

We see that we actually have 2 revisions and the second revision gets 100% of the traffic. How come we have 2 revisions? Well, remember we changed the concurrency limit on our service? That’s when a new revision was created:

> kn revision describe helloworld-pflmj-2
Name: helloworld-pflmj-2
Namespace: default
Age: 3m
Image: gcr.io/knative-samples/helloworld-go (pinned to 5ea96b)
Concurrency:
Limit: 10
Service: helloworld
Conditions:
OK TYPE AGE REASON
++ Ready 3m
++ ContainerHealthy 3m
++ ResourcesAvailable 3m
I Active 2m NoTraffic

We clearly see the concurrency limit set to 10 in this revision.

Autoscaling a Knative service

Now we are ready to generate load on the service. We will use a tool called hey, but hey, you are welcome to use a tool of your choice:

> hey -z 30s -c 50 "http://helloworld.default.127.127.127.127.xip.io"

This will generate 50 concurrent requests to our service during 30 seconds. Since our concurrency limit was set to 10, we now expect 5 pods to get started to handle all the traffic.

Our watch confirms our theory:

> watch kubectl get pod
NAME READY STATUS RESTARTS AGE
pod/helloworld-pflmj-2-deployment-84789457b-2cvzw 2/2 Running 0 13s
pod/helloworld-pflmj-2-deployment-84789457b-lzcv8 2/2 Running 0 13s
pod/helloworld-pflmj-2-deployment-84789457b-qm9ds 2/2 Running 0 14s
pod/helloworld-pflmj-2-deployment-84789457b-rf75q 0/2 ContainerCreating 0 11s

pod/helloworld-pflmj-2-deployment-84789457b-rhj65 0/2 ContainerCreating 0 13s

Again, after becoming idle these pods will be terminated.

Routes

But what if we want to deploy a new version of our app but not move it in production yet?

Our helloworld app supports an environment variable TARGET — if we set it to a message, that message will be returned to us in the response. So let’s use that to simulate releasing a new “testing” version of our app.

Obviously, doing kn service update helloworld --env TARGET=testing doesn’t work because this will route all traffic to the new version which we wanted to prevent.

To make this work, we first need to specify that the traffic should remain on the current version. We will use the feature called ‘tags’:

> kn service update helloworld --tag helloworld-tprvf-2=production --traffic production=100

> kn revision list
NAME SERVICE TRAFFIC TAGS GENERATION AGE CONDITIONS READY REASON
helloworld-tprvf-2 helloworld 100% production 2 94s 3 OK / 4 True
helloworld-mtfrw-1 helloworld 1 101s 3 OK / 4 True

We defined a tag ‘production’, assigned it to the current version and specified that it should get 100% of the traffic. Now we can deploy a new testing version and tag it as testing:

> kn service update helloworld --env TARGET=testing
> kn revision list
NAME SERVICE TRAFFIC TAGS GENERATION AGE CONDITIONS READY REASON
helloworld-rstwg-3 helloworld 3 55s 4 OK / 4 True
helloworld-tprvf-2 helloworld 100% production 2 94s 3 OK / 4 True
helloworld-mtfrw-1 helloworld 1 101s 3 OK / 4 True
> kn service update helloworld --tag helloworld-rstwg-3=testing
> kn revision list
NAME SERVICE TRAFFIC TAGS GENERATION AGE CONDITIONS READY REASON
helloworld-rstwg-3 helloworld testing 3 12m 4 OK / 4 True
helloworld-tprvf-2 helloworld 100% production 2 13m 4 OK / 4 True
helloworld-mtfrw-1 helloworld 1 13m 3 OK / 4 True

We have now tagged our new version as ‘testing’. 100% of the traffic is still sent to production, as we see in the revision list. It turns out that tagging automatically creates a new route so we can access our testing version as follows:

> curl http://testing-helloworld.default.127.127.127.127.xip.io

Hello testing!

> curl http://helloworld.default.127.127.127.127.xip.io

Hello World!

We can now test our new version in isolation.

Blue and green canaries

After testing, we are now ready to move our testing version to production. Since production is the only really representative testing environment, instead of replacing the production version immediately, we would like to send a percentage of the traffic to the new version — a process called ‘canary testing’ or ‘canary deployment’.

> kn service update helloworld --traffic testing=10,production=90
> kn revision list

NAME SERVICE TRAFFIC TAGS GENERATION AGE CONDITIONS READY REASON
helloworld-rstwg-3 helloworld 10% testing 3 21m 4 OK / 4 True
helloworld-tprvf-2 helloworld 90% production 2 22m 4 OK / 4 True
helloworld-mtfrw-1 helloworld 1 22m 3 OK / 4 True

We now see the intended traffic distribution. If we now do

> curl http://helloworld.default.127.127.127.127.xip.io

we will get about 10% of “Hello testing!”s and 90% of “Hello World!”s. After we are satisfied that our testing revision is performing properly, we can tag our testing version as production and send 100% traffic to is using the mechanisms explained above.

A different approach is a so-called “blue-green” deployment. In that scenario, we imagine that our current production environment is tagged ‘blue’. We tag the new production version ‘green’ and switch 100% of the traffic to it. If drama happens, we quickly switch traffic back to ‘blue’ and start solving bugs in ‘green’.

Let’s start from scratch. First, let’s delete our service:

> kn service delete helloworld

Let’s create our blue version:

> kn service create helloworld --image gcr.io/knative-samples/helloworld-go --env TARGET=blue --revision-name blue

Here, we used the --revision-name option to specify the revision name instead of letting Knative generate one for us. This means that we can use the revision name and can omit the tagging. In practice, tagging is more flexible because that is independent of revisions and moving a tag is easier than renaming revisions.

Next we will pin 100% traffic to the blue version so traffic will stick to it when we deploy a new revision:

> kn service update helloworld --traffic helloworld-blue=100
> curl http://helloworld.default.127.127.127.127.xip.io
Hello blue!

We see that the blue version is now live. Let’s now create our green version:

> kn service update helloworld --revision-name green --env TARGET=green
> kn revisions list
NAME SERVICE TRAFFIC TAGS GENERATION AGE CONDITIONS READY REASON
helloworld-green helloworld 2 5m35s 3 OK / 4 True
helloworld-blue helloworld 100% 1 7m27s 3 OK / 4 True
> curl http://helloworld.default.127.127.127.127.xip.io
Hello green!

We successfully switched to the green version. We can switch back anytime:

> kn service update helloworld --traffic helloworld-blue=100
> curl http://helloworld.default.127.127.127.127.xip.io
Hello blue!

That was easy — we just implemented a blue-green deployment!

Please note that the real world is often tricker, especially if you have a storage backend with changing schema across service versions. Knative is still a big help, since it removes a lot of burden from deploying the web services themselves.

Knative Dashboards

Knative comes with pre-configured monitoring components. In this example we have installed Grafana and Prometheus, which enable us to view nice dashboards of our services.

This command will forward the localhost port 3000 to the grafana service in our kubernetes cluster:

> kubectl port-forward --namespace knative-monitoring $(kubectl get pods --namespace knative-monitoring --selector=app=grafana --output=jsonpath="{.items..metadata.name}") 3000

Now, we can access the dashboards via ”http://localhost:300” in our local browser.

Epilogue

Summarizing, we have explored:

Installing Knative
Deploying and (auto)scaling a service
Canary and blue-green deployments
Knative Dashboards

I hope this overview has provided you with enough information and got you excited to start exploring Knative for yourself.

References:

If you are interested in moving your CI/CD pipeline to Kubernetes, check out the Tekton blog by Eric Sorenson. Fun fact: Tekton originated from a third component of Knative, “Build”, which has since then moved away from Knative into the Tekton project.

This educational content is brought to you by Relay. Relay is an event-driven automation platform that pulls together all of the tools and technologies you need to effectively manage your DevOps environment.

4 Tips from an Engineering Director to Build Reliable Automation

Melissa Sussmann — Wed, 22 Apr 2020 19:34:42 +0000

4 Tips from an Engineering Director to Build a Reliable Automation Platform

By: Brad Heller, Engineering Director at Puppet

Every company under the sun relies on automation to make business hum. Getting leverage out of technology is the reason the world’s biggest companies can operate efficiently at a mind-boggling level of scale. In fact, one could argue that the generalized pursuit of advancement in technology is, by and large, the process of automating human work but…that’s a topic for another blog post.

As an engineering leader in the tech industry, building a high-performing DevOps team and culture can be daunting when you’re just getting started. But you need not master Google’s SRE practices to get started with high-quality automation.

In this post we’ll explore a few techniques that we’ve learned for improving upon the automation your engineers write and maintain. We’ll talk about why you need a robust platform that provides a repeatable and consistent environment for your automation to run in. We’ll also discuss some techniques for making your automation more reliable and easier to use and maintain.

1: Create a one stop automation shop

All automation platforms are conceived as a simple script on an engineer’s laptop written to perform some sort of maintenance task. Often the next step is to take this script and share it with coworkers (typically via a git repository). This script will live on to be invoked on demand from your engineers’ laptop whenever they need it.

Be proactive: Create a simple Rails or Django app that your engineers can use to centralize their maintenance work. Congratulations, you now have an automation platform. This provides a consistent environment for your automation to run in, eliminating entire classes of problems. It also makes it a whole heck of a lot easier for you to audit who’s invoking automation, when, and why.

To keep your automation platform low-overhead is to use a framework like ActiveAdmin to build out your screens quickly. It provides a lot of flexibility and can grow with your organization. Between that tool and Ruby on Rails itself there are a lot of plugins that give you out-of-the-box integration with other tools you might use like Okta or SalesForce.

2: Treat your automation like you treat your product

The automation that makes your business tick is as important as the thing you’re selling and you should treat it as such. Your automation platform should have a backlog, a team assigned to it, and an owner. It should likewise have a test suite, a deployment pipeline, monitoring and alerting, and staged releases — just like a product would.

Just like with any new product, you can get started by simply cataloging feature ideas and requests for your automation platform in your tool of choice for organizing your engineering work. At Puppet most teams use JIRA internally but since this team is a bit more scrappy we use Trello.

3: Make Automation Accessible to Everyone

There are many different types of stakeholders that need to interact with your new automation platform. Sales and product management need usage reports. Marketing needs business process automation for their next digital campaign. Support needs to be able to perform maintenance on customers’ accounts. Executives need reports on growth metrics.

Folks should be able to push a button to do their job. Spend the energy in creating a simple UI for invoking, monitoring the progress of, and reporting on your automation. If you put an API in front of it you can quickly and easily write command line tools that technical users can use to invoke automation and integrate your platform with other systems.

A great example of a tool that bridges the gap between both technical and non-technical users in a similar way is Google Data Studio. It provides a really robust set of tools for developers to create the reports their users need, as well as a familiar interface for non-technical users to get access to and explore their companies’ data.

4: Usage hack: Pull in your company’s existing reports

An easy way to encourage more usage of and to get users used to your automation platform is to embed commonly-used reports from your reporting tools directly into the platform. Most tools, like Google Analytics or Looker, provide the ability to directly embed dashboards into other apps.

These are just a few ways you can make your automation life easier. Don’t be fooled, however: They are born from years of toil with creating simple, reliable automation for companies and products.

At Puppet, we’ve taken many of these concepts and baked them directly into Relay, our DevOps automation platform. Take a look and sign up for updates on our upcoming beta launch — we’d love to hear how it stacks up against your own tools! Relay is an event-driven automation platform that pulls together all of the APIs and configuration management tools you need to effectively run your DevOps environment.

What is Knative? Learn How to Install and Use Knative with Zero YAML

Melissa Sussmann — Wed, 15 Apr 2020 15:15:32 +0000

A quick overview for the impatient reader: By Dimitri Tischenko

Kubernetes is complex, but powerful!

Introduction

If you have some experience with Kubernetes, you will appreciate its power but also its complexity. No-ops world with Kubernetes seems utopic. You wish there was something simpler, finally giving developers the power to self-service. Fortunately, Knative has been designed exactly with this purpose in mind: give developers a simple way to deploy and manage their services, abstracting away the more ops-y Kubernetes concepts such as pods, nodes and ingress.

Since you are busy pushing new releases to production and don’t have any time to waste, this article will try to present Knative to you using “the path of least resistance”. Simplicity over completeness and imperative commands over yaml declarations.

Knative: A simpler way to deploy and manage services

Knative provides two high-level abstractions

Knative Serving: an set of components for deploying and managing revisions of stateless Web microservices. Think “one command to deploy an app and provide an url to access it”. This article will concentrate on the serving component.
Knative Eventing: a framework for configuring event pipelines between various microservices. We will leave Knative Eventing as an exercise to the reader or future blog articles.

So let’s jump in.

Installing Knative

By far the easiest Knative installation method I found is to follow this excellent setup guide by Mete Atamel. It assumes GKE (Google Kubernetes Engine) but will also work on other K8S implementations. The link above is to my fork of that guide with the monitoring setup added.

After installing, make sure you check that everything is running properly by executing the following three commands:

> kubectl get pods -n knative-serving
NAME READY STATUS RESTARTS AGE
activator-869f6d4f9f-jxxfn 1/1 Running 0 118m
autoscaler-78994c9fdf-97c7k 1/1 Running 0 118m
controller-b94c5b667-cn2sm 1/1 Running 0 117m
default-domain-btzn4 0/1 Completed 0 117m
networking-istio-5847754959-p7g78 1/1 Running 0 117m
webhook-7cdb467d79-9mgf2 1/1 Running 0 117m

 > kubectl get pods -n knative-eventing
NAME READY STATUS RESTARTS AGE
broker-controller-b85986f7d-8lzwn 1/1 Running 0 117m
eventing-controller-58b889c4b4-gdt67 1/1 Running 0 118m
eventing-webhook-5549c4b664-ltq69 1/1 Running 0 118m
imc-controller-64cfbf485d-7jz2j 1/1 Running 0 117m
imc-dispatcher-5fc7ccf7d8-6jbfr 1/1 Running 0 117m

> kubectl get pods -n knative-monitoring
NAME READY STATUS RESTARTS AGE
grafana-5cb855689f-frgfc 1/1 Running 0 113m
kube-state-metrics-5cb5c6986b-t7m7w 1/1 Running 0 113m
node-exporter-8tn78 2/2 Running 0 113m
node-exporter-mz5kk 2/2 Running 0 113m
node-exporter-wjfvd 2/2 Running 0 113m
prometheus-system-0 1/1 Running 0 113m
prometheus-system-1 1/1 Running 0 113m

You can also run the “./check-versions” script provided in the setup folder. This article was written using version 0.13 of Knative.

Knative CLI: kn

This article will use Knative CLI called kn for the experiments because it’s the easiest way to interact with Knative. It is of course also possible to interact with Knative using kubectl if you so prefer. Since I promised you “zero-yaml”, that is left as an exercise to the reader.

Let’s go ahead and deploy a sample “Hello World” application.

Deploying a Knative service

> kn service create helloworld --image gcr.io/knative-samples/helloworld-go
> kn service list
NAME URL LATEST AGE CONDITIONS READY REASON
helloworld http://helloworld.default.127.127.127.127.xip.io helloworld-10 110m 3 OK / 3 True

That’s impressive. We have deployed a web microservice with one command and we now have an url we can use to access it: http://helloworld.default.127.127.127.127.xip.io (IP address replaced by a fake one to prevent misunderstandings). Note that xip.io is the “magic” DNS provider which is automatically configured during this demo setup. Xip resolves names with the pattern *.[ip].xip.io to ip address [ip].

Let’s “peek under the hood” on the Kubernetes level to see what is happening. Did Knative actually create a pod for us?

> kubectl get pod
No resources found in default namespace.

Hmm, we don’t have any pods running! How does our microservice work, then?

Let’s start

watch kubectl get pod

in one terminal, and hit our helloworld app with curl in another:

>curl http://helloworld.default.127.127.127.127.xip.io
Hello World!

It worked, the app returned the string “Hello World!”. Our watch now shows a running pod:

> watch kubectl get pod
NAME READY STATUS RESTARTS AGE
helloworld-10-deployment-6844684bdf-zdgxb 2/2 Running 0 10s

So Knative started our service when we actually accessed it! And what’s more, if we wait another 60 seconds, the pod will disappear — Knative scales back to zero if the service is not used. This is an example of autoscaling from 0 to 1 and back to 0.

I hope this was useful to readers as an introduction to installing and running a “Hello World” example with Knative. Please tune into the rest of this series as I share more with readers on how to Configurations, Routes, Blue/Green deployments, and more!

References:

This educational content is brought to you by Relay.sh. Relay is an event-driven automation platform that pulls together all of the tools and technologies you need to effectively manage your DevOps environment.

Learn 10 Free Tips to Squash Digital Viruses During a Novel Work-From-Home Era

Melissa Sussmann — Wed, 01 Apr 2020 21:57:42 +0000

Edited to include markdown. Originally posted here

I am making a digital transformation during this novel work-from-home (WFH) era due to a COVID-19 quarantine. Many of you are going through the same and distractions abound while sharing a workspace with housemates, children, and pets. Moreover, we have to contend with an increased risk to cybersecurity, given recent attacks on work-related software such as Slack and Zoom.

Despite exposing millions of accounts to attack, these companies provide
critical infrastructure for helping millions in quarantine be productive from
home. There is also an uptick in social engineering attacks that capitalize on
COVID-19 related business disruptions by attempting to deliver ransomware in phishing emails. Here are 10 tips I follow to provide immunity against digital viruses in my WFH environment.

1. Always use a camera cover and mute your microphone unless you are actively on a call.

While my encrypted connection is relatively secure, I am still leaving myself open to attack from third-party conferencing software without this precaution. Even if an attacker were to take over my Slack account or listen into my zoom calls, they would still not be able to access my microphone or video with a cam cover and a muted mic.

My laptop has a built-in cam cover but you can also use a sticker

2. Use a Virtual Machine (VM) for your personal use.

I do not store personal data (including web browsing) on my work laptop and instead use a free VM. Set up a separate, encrypted virtual machine to use as a personal environment for private searches and documents you want to have available on your work laptop. Never sign into personal accounts on your work computer while outside of this carefully siloed environment.

This is the encrypted VM that I use for personal files + browsing

3. Connect via VPN.

During work hours, my VPN is active and pings a private network in order to authenticate my entrance to Puppet portals. Most organizations use VPN connections to authenticate access for your work accounts through an encrypted connection to your work server. This prevents Internet Service Providers (ISPs) from accessing your private data.

4. Use HTTPS when web browsing.

Unless you have municipal broadband, you use an Internet Service Provider (such as Comcast). ISPs have access to your private data while web browsing (even through incognito mode) if you are not using an encrypted connection. If you are not connected to a VPN, make sure all websites you access are using HTTPS, which leverages SSL security. Pay attention if your browser warns you that you are getting an “invalid certificate”. This means that your connection is no longer encrypted.

Bail. Go “back to safety” when you see this!

5. Ensure you connect to a trusted, encrypted wi-fi network

If you are using Windows, your network should be configured with the “Public” Network Type setting checked. This ensures that network discoverability and “File and Print Sharing” are turned off. Otherwise, you expose your domain, machine name, mac address, and IP address for your local network. Also, your publicly shared folders will be available (potentially with read and write access) to anyone on the network. Moreover, there are many connections that are still vulnerable to port scanners and keyloggers that connect through certain wireless keyboard dongles. These attack vectors are especially common in apartment and condo complexes, where physical distances and networks are closer together.

These are my recommended network settings (on Windows)

6. Turn off scripts when web browsing.

Install the plugin “NoScript”. Then, whitelist acceptable domain names that are relevant to your work. Scripting is a common attack vector that uses scripts to pull data from your computer like your clipboard or your browser’s cache and cookies. The malicious actor could potentially gain access to your login credentials (through cookies) to other secured websites.

I use Firefox with NoScript on my add-ons

7. Create strong passwords (with two-step authentication)

Try to use “pass phrases” that are easy to remember (i.e. I7oveD1sney7and!). This gives you length and variety to your password so that it is robust enough to be secure while still easy enough to remember. If you use two-step verification, attackers would not be able to log into your accounts, even if they have your password…so set that up!

8. Don’t install executable files

…from un-trusted publishers. They are probably keyloggers or computer viruses. No, “watch-cute-animals-now.exe” is not worth the risk. Also, keep user account control enabled (in Windows) so you have to authorize all installations.

9. Check the domain name

Try to not click on random links and make sure you are not on “mellsfargo.com” or other similar sites. Double-check your entry for spelling errors when you type in URLs such as: “https://relay.sh” (where I work).

10. Check your firewall and anti-virus settings

While I do not feel the need to run anti-virus software on my linux VM, most of you lovely readers are probably using Windows. Windows Defender is free and the only anti-virus software you need. Firewall settings come pre-configured too! For the Apple users: You are in luck because there aren’t as many viruses for macs. However, let me point you to this PC Magazine article to learn more. Please remember that virus scanners are only useful if you run manual scans and keep up with updates.

Conclusion

Hopefully this guide serves to help quarantine your computer from digital viruses during your WFH transition. Please comment and leave some of your own tips!