I prefer using GraphQL over REST APIs wherever available, primarily because I can avoid overfetching and underfetching data while still enjoying the benefits of contract-based development.
For this exercise, assume that you are the DevOps lead of an organization/open-source community that uses GitHub to manage its projects under a GitHub Organization. GitHub Organizations are shared accounts consisting of members and projects with sophisticated security and administrative features. You have been asked to ensure that your organization's repositories are healthy such that there are no PRs in an unmerged state for more than one week, and every issue is either resolved or updated in 12 hours.
Scheduling Jobs on Heroku with Azure Logic Apps
Many times, your application needs to run tasks or jobs on regular intervals. Scheduling might be necessary when polling an API every night, or dispatching emails with reports each week. And sometimes you may find that you need to trigger a host of tasks across multi- or hybrid-cloud and need a way to run these tasks in a reliable, cross-cloud manner.
In this article, let’s look at one way to do that using a Heroku dyno for our task, and Microsoft Azure Logic Apps as our scheduler service. The scheduler in Logic Apps allows for triggering workflows that include services across clouds and on-premises, paving the way for easy administration and observability of many disparate tasks. Functionally, the scheduler not only lets you specify simple recurrence rules (such as every minute), but also complex ones (such as every 15 minutes during work hours).
Implementing Multi-Session Sequential Convoy Pattern with Azure Service Bus and Go
In many event-driven applications, preserving the sequence of events is essential. For example, an event-driven eCommerce application might have the following states, transitions, and events.
- A user adds N items to the basket. This action generates the item added event.
- The user checks out the basket. This action generates the basket checked out event.
- The user pays for the items. This action generates the payment made event.
- Inventory decrements the count of available items by N. This action generates the inventory updated event.
For such an application to function correctly, it is critical to maintain the sequence of events. For instance, processing the payment made event before the basket checked out event might lead to errors in billing or inventory systems. In a horizontally scalable system, we can not guarantee sequential processing of messages without creating groups of messages so that the service bus always delivers the messages within a group in sequence. The message consumer must finish processing a message and update the status of the message to the service bus before the next message in the sequence is delivered to it. Azure Service Bus supports the concept of the grouping of related messages through the message sessions feature.
Simplifying ARM Template Deployments With Ansible
I discussed how you could use Ansible with Terraform to simplify configuration management in my previous post. If, instead of Terraform, you prefer using Azure Resource Manager (ARM) templates to define the infrastructure and configuration for your project, you can use Ansible for managing parameters that customize each environment by dynamically generating a Resource Manager parameters file.
A great thing about using Ansible for your ARM configuration needs is that it includes a suite of modules for interacting with Azure Resource Manager. You can install the modules using Ansible Galaxy, a repository of Ansible Roles that you can drop directly in your Playbooks.
Serverless Visitor Counter Badge with Azure Functions
We all love web badges. You might have spotted many of them in README of repositories, including the repository of my blog, The Cloud Blog. In general, web badges serve two purposes.
- They are visually appealing.
- They display key information instantly.
If you scroll to my website's footer section, you will find GitHub and Netlify badges that display the status of the latest build and deployment. I use them to quickly check whether everything is fine with the world without navigating to their dashboards. In essence, a badge is an SVG image with dynamic content embedded in it.
Simplifying Terraform Deployments with Ansible – Part 2
In this series:
- Part 1: Motivation & Ansible 101
- Part 2: Terraform & Ansible
I am happy to see that many people are enthusiastic about this series and wish to make their IaC applications better with Ansible. What I intend to do is quite simple. I will write an Ansible playbook that uses the template module (see Templating with Jinja2) and a little magic of Jinja2 templates to load appropriate variables and configurations for each Terraform environment. Finally, I will use the Terraform CLI to deploy and delete the infrastructure.
Simplifying Terraform Deployments With Ansible – Part 1
Enterprise developers are responsible for deploying infrastructure to multiple environments, such as development, staging, and production. One core problem with configurations in Terraform is that with the number of environments and variables, the number of ".tfvars" files used to manage configurations will increase. Several tools, such as Puppet, Chef, and Ansible, help simplify the management of configurations.
Ansible
Ansible is an open-source configuration management and deployment tool. It has a unique declarative language for describing system and application configurations.
Generating Dynamic Open Graph Images With Azure Functions
Open Graph (OG) tags allow you to control what content shows up when you share the webpage on major social media sites such as Facebook, Twitter, and Google. The essential Open Graph properties that you must configure in the <head> section of your webpage are the following.
og:title: The title of your webpage.og:image: An image URL displayed as the thumbnail of your webpage when it is shared. The recommended dimension of this image is 1200px X 627 px.og:url: The canonical URL of your webpage.
Azure Functions now supports running headless Chrome on Linux, and with this feature, you can now run browser automation tools such as Puppeteer on Azure Functions. Since this feature is also available on the consumption plan, you can keep the cost of running such functions very low by only paying for the processing capacity that you utilize.
No Code Incident Management System with Azure Logic Apps
In this lab, we will create an Azure Logic App that monitors Twitter, analyzes the sentiment of customer tweets with Text Analytics v2 service, and creates incidents in Pager Duty. PagerDuty is an incident management platform that provides reliable notifications, automatic escalations, on-call scheduling, and other functionality to help teams detect and fix problems quickly. This application can help customer service agents react swiftly to customer complaints and avoid brand reputation damages.
Text Analytics Cognitive Service
You will require an active Azure subscription for building this project. If you do not have one, signup for a free account here. Next, you will need a Text Analytics API Key to access the sentiment analysis service. Enter the text "Text Analytics" in the search box on the Azure portal. From the search results, select the Text Analytics service.
Cheapskate’s Journey to On-Demand Load Tests on Heroku With Locust
I want to stretch every dollar that I spend on the cloud. I run a handful of web applications on Heroku, and like everyone else, run a suite of smoke tests and load tests on every release increment in a non-production environment. Load tests are important: they help us not only to understand the limits of our systems but also bring up issues that arise due to concurrency, which often escape the realms of unit tests and integration tests. But since we run the tests often, we don’t want to pay a lot of money every time the tests run.
In this article, I’ll show you how to set up cost-effective load tests. We’ll use Locust to make the testing robust and Heroku to make running the tests easy and cost-effective. I’ll also show how you can use VS Code and Docker for development without installing dev dependencies on your system.
Using Startup Command to Pass Command Line Arguments to Azure App Service for Linux
Azure App Service on Linux has several prefabricated Docker images that support applications written in languages such as .NET core, PHP, and Node.js. App Service also supports using your own Docker image to spin up a container for your application. A useful configuration feature of App Service on Linux is the Startup File configuration that you can set as part of configuring the runtime stack. The value that you specify for the configuration overrides the CMD instruction of the Dockerfile that creates the runtime of the application. If you are not aware of this configuration option, we will soon deploy an application that uses this configuration option soon, so keep reading.
The Docker documentation states that if your Dockerfile has both CMD and ENTRYPOINT instructions, then CMD arguments are appended to the end of the command generated by the ENTRYPOINT instruction. A necessary condition for this feature to work is that you must use the exec form of the ENTRYPOINT instruction in your Dockerfile. In simple terms, assume that your Dockerfile has the following instructions.
VS Code Remote Development With Docker Compose: Developing Services in Standalone and Integrated Modes
VS Code remote development is a brilliant feature from the VS Code team. Using the extensions available in the VS Code remote extension pack, you can develop your applications in an external development environment viz. a remote server (through SSH), containers, and WSL. The premise of the three modes of development is the same. The application code is stored either on your local system (on container and WSL through volume mount) or remote server (through SSH), and the local instance of the VS Code attaches itself to the external system through an exposed port (container and WSL), or SSH tunnel (remote server). For a developer, this experience is seamless and requires a one-off setup. VS Code is responsible for the heavy lifting of the entire experience of remote development.
Let’s discuss some of the everyday use cases of remote development. The primary use of remote development is to develop and test Linux compatible apps with WSL on Windows. Remote development allows you to use a remote machine with better specs for development (e.g., code and debug on your desktop from your tablet), which is another use of the feature. However, the most beneficial use case for most developers working in a team environment is that they now can specify the development environment (including VS Code extensions) in the form of Dockerfiles and container specifications, and add them to the source control. With the configurations in place, anyone can recreate the development environment and be productive immediately.
Durable Cloud Event Production From Knative Container Source With Azure Durable Task Framework
Knative is an excellent platform for building, deploying and managing serverless workloads on Kubernetes. The Serving resources of Knative extend Istio to support serverless applications. Another class of resources of Knative called Eventing extend Istio to support the production and consumption of Cloud Events.
Integrated CI/CD in Azure Pipelines as Code With Key Utils: Binary Logger and Report Generator
If you are using Azure DevOps for building and deploying your .NET core applications, then you should consider the following.
Origin Authentication and RBAC in Istio with Custom Identity Provider
The concept of access control can be boiled down to two factors: authentication (AuthN) and authorization (AuthZ). While authentication determines the identity of a client based on the data presented to the identity provider (e.g., Google and Microsoft AD), authorization determines whether an authenticated principal may interact with the resource.
Istio supports Token-based end-user authentication with JSON Web Tokens or JWT. In terms of Istio, the process of authentication of the end-user, which might be a person or a device, is known as origin authentication. Istio allows you to validate nearly all the fields of a JWT token presented to it. Since JWT is an industry-standard token format, the origin authentication feature of Istio is compatible with OpenID connect providers such as Auth0, Google Auth, and Key Cloak.
Using CoreDNS to Conceal Network Identities of Services in Istio
A crucial feature of the Istio Service Mesh is that it grants you absolute control over how you want to route traffic to a service. Each service on the Istio service mesh has a unique network identity that it receives from the underlying host, i.e., Kubernetes.