Showing posts with label devops. Show all posts
Showing posts with label devops. Show all posts

Wednesday, June 1, 2022

Stress test your cloud applications with Azure Chaos Studio

Azure Chaos Studio makes it possible to stress test your applications directly from Azure, and can significantly help in your business continuity and disaster recovery (BCDR) strategies.

Azure Chaos Studio
Source: Azure

Azure Chaos Studio is a new service in Azure that allows you to test and improve the reliability of your applications. With it, teams can quickly identify weak spots in their architecture, addressing the enterprise goals of business continuity and disaster recovery (BCDR).

Subjecting applications to real or simulated faults allows observing how applications respond to real-world disruptions.

Running chaos experiments used to be a complex task and required deploying very complex workloads. But with Chaos Studio it just became less complex, due to its availability from the Azure portal.

Azure Chaos Studio - Console
Source: Azure

What is Chaos Engineering?

Chaos engineering is a practice that helps teams measure, understand and improve their cloud applications by submitting those application to failures in controlled experiments. This practice helps identifying weak spots in your architecture, which if fixed, increases your service resilience.

Why Chaos Engineering?

The problem that Chaos Studio tries to solve is not new. Disaster recovery and business continuity are usually treated very seriously by organizations as outages can significantly impact reputations, revenues, and much more.

That said, practicing chaos engineering is a must for organizations actively working on business continuity and disaster recovery (BCDR) strategy. These drills ensure that applications can recover quickly and preserve critical data during failures.

Another important factor to consider is high availability (HA). Chaos Engineering helps validating application resilience against regional outages, network configuration errors, high load, and more.

Features

Some of the most interesting features provided by Azure Chaos Studio are:

  • Test resilience against real-world incidents, like outages or high CPU utilization
  • Reproduce incidents to better understand the failure.
  • Ensure that post-incident repairs prevent the incident from recurring.
  • Prepare for a major event or season with "game day" load, scale, performance, and resilience validation.
  • Do business continuity and disaster recovery (BCDR) drills to ensure that your application can recover quickly and preserve critical data in a disaster.
  • Run high availability (HA) drills to test application resilience against region outages, network configuration errors and high stress events.
  • Develop application performance benchmarks.
  • Plan capacity needs for production environments.
  • Run stress tests or load tests.
  • Ensure that services migrated from an on-premises or other cloud environment remain resilient to known failures.
  • Build confidence in services built on cloud-native architectures.
  • Validate that live site tooling, observability data, and on-call processes still work in unexpected conditions.

How to get started

Getting started with Azure Chaos Studio is simple, just log into your Azure Account and follow these steps.

References

Posted by
Labels: , , , , , ,

Monday, May 2, 2022

Managed Grafana now available on Azure

It's now possible to run Grafana natively on Azure. Read to understand.

Source: Azure

Grafana, the most popular open-source analytics visualization tool is now available on Azure as a managed service. With it, customers can run Grafana natively within the Azure cloud platform without needing to provision or managing the backend services needed to run it.

Why use Grafana?

With Grafana, users can bring together logs, traces, metrics, and other disparate data from across an organization, regardless of where they are stored. With Azure Managed Grafana, the Grafana dashboards our customers are familiar with are now integrated seamlessly with the services and security of Azure.

Features

Azure Managed Grafana is a fully managed service for analytics and monitoring solutions. It's supported by Grafana Enterprise, which provides extensible data visualizations. Quickly and easily deploy Grafana dashboards with built-in high availability and control access with Azure security.

Source: Azure

Azure Managed Grafana also provides a rich set of built-in dashboards for various Azure Monitor features to help customers easily build new visualizations. For example, some features with built-in dashboards include Azure Monitor application insights, Azure Monitor container insights, Azure Monitor virtual machines insights, and Azure Monitor alerts.

How to get started

Getting started with Grafana on Azure is easy. Here are some links you should check:

References

Posted by
Labels: , , , , , , , , ,

Thursday, April 1, 2021

Building and testing Node.js apps with Azure DevOps Pipelines

Learn how to built, test and run code coverage analysis on a Node.js app using Azure DevOps Pipelines
Photo by Chirstopher Gower on Unsplash

Setting up an Azure DevOps pipeline is not too complicated. On this tutorial, let's learn how to setup a simple pipeline to a basic Node.js app so we can build, test and capture test results and report code coverage analysis, exposing them to everyone in the team.

On this tutorial we will:

  • Create a new DevOps Pipeline
  • Build our project
  • Configure DevOps to read the outputs of our tests and test coverage

Sample Project

This tutorial can be executed using this repository. 

Setting up a Connection

To get started, we have to grant Azure DevOps access to your external repo, GitHub on this case. To configure a new connection, click on Project Settings on the bottom left in your navigation bar:

Then click on Boards -> GitHub connections:

Now, click on New Connection:

And click Connect your GitHub account:

Finish the integration by entering your username/password and authorizing access to your GitHub account and repositories.

Creating a new DevOps Pipeline

Now that your Azure DevOps has access to your GitHub repos, let's build our first pipeline. Click on Pipelines -> New Pipeline on top right to create a new one:

Choose a source repository

Next, select where your project is located. Since we're using GitHub for this demo, click on it:

And choose, one of your existing repositories:

Configuring the Pipeline

Next, DevOps will ask you to specify your project type. Since we're building a Node.js project, choose it from that list:

Click Next and you should see a default build yaml for your new project that should look more a less like this:

pool:
  vmImage: 'ubuntu-latest'

steps:
- task: NodeTool@0
  inputs:
    versionSpec: '10.x'
  displayName: 'Install Node.js'
- script: |
    npm install
    npm run build
  displayName: 'npm install and build'

Running our first build

If all your dependencies can be satisfied by npm, most likely your project can be built so click Save and run so that DevOps builds your project for the first time:

By clicking on the columns on the left, we can even inspect the result of the build. For example, here's the output of npm install and build:

Coming back to out pipeline page, we get our first successful build:

Step 4 - Setup Unit Test reporting

But as good as the initial template is, it does not auto-enable unit-testing and code coverage reporting, so let's set it up. To change the pipeline in the future, click on the Dots menu -> Edit Pipeline:

You'll be redirected to the editor. On the Tasks menu on the right, type test results and click on Publish Test Results to add it as a new task in our azure-pipelines.yml file:

Next screen, select JUnit, follow the configuration below and click Add:

Step 5 - Setup Code Coverage reporting

Similarly, type code coverage on the Tasks menu on the right, to add the code coverage task:

And set:

  • Coverage tool: Cobertura
  • Summary file: coverage/cobertura-coverage.xml

Review and Save

The above steps should have added something similar to the below on your azure-pipelines.yml:

- task: PublishTestResults@2
  inputs:
    testResultsFormat: 'JUnit'
    testResultsFiles: '**/TEST-*.xml'
- task: PublishCodeCoverageResults@1
  inputs:
    codeCoverageTool: 'Cobertura'
    summaryFileLocation: 'coverage/cobertura-coverage.xml'
The menus and buttons we clicked are nothing more than helpers to add the above code. Feel free to explore the editor and properties for each field since it contains intellisense.

Click Save and Run again to produce a new build. Once your build is finished, it should show up in the pipeline's main screen:

Reviewing Test Results and Test Coverage

To wrap it up, let's review our test results/coverage reports. Clicking on the second build should take you to the build page:

Highlighted in the above image, both are links that take us to the tests page so we can review test results:

Cool, isn't it? Clicking on the cover tests link above, we're taken to the Code Coverage page where we're able to see the code coverage in our project:

Conclusion

On this article we reviewed how to setup a simple Azure DevOps pipeline to build, test and report code coverage for a basic NodeJS app exposing them in the build. Azure DevOps is a pretty powerful CI/CD system but unfortunately, often ignored by the community. Feel free to explore it!

Source Code

As always, the source code for this post is available on my GitHub.

References

See Also

Posted by
Labels: , , , , , , , , , , ,

Tuesday, March 2, 2021

Continuous Integration with Azure App Services and Docker Containers

Enabling continuous integration between your Azure App Services and Docker Containers is simple. Learn how.
Photo by Jason Leung on Unsplash

Following up on a previous post where we learned how to deploy our own Docker Images to Azure App Services, today we will learn how to enable continuous deployment between our App Service and our Azure Container Registry so that our ASP.NET website is automatically updated whenever a new image is pushed to our private repository.

On this post we will:

If you want to follow along, please check the previous tutorials discussing how to:

  • Build a simple ASP.NET Core image on your local Docker repository
  • Create and push a Docker Image to your own Azure Container Registry
  • Deploy Docker images to Azure App Services

Requirements

As requirements, please make sure you have:

Why Continuous Deployment?

Before getting to the code, let's understand a little more about continuous deployment. Wikipedia defines it as, 
a software engineering approach in which software functionalities are delivered frequently through automated deployments.
And why practice CD? Still according to Wikipedia, CD is especially important because in an environment in which data-centric microservices provide the functionality, and where the microservices can be multiply instantiated, CD consists of instantiating the new version of a microservice and retiring the old version as it has drained all the requests in flight.

Reviewing our App Service

So let's start by reviewing our application. We will resume from a previous post where we explained how to deploy our Docker images to App Services. Our app looked like this:

Our App Service Panel

Here's its Azure panel:

Container Services

And here's the configuration used on the previous deployment:

Image Setup

Notice that because we're switching to continuous deployment and we'll be constantly changing the version number so sticking with v1 will no longer work. On this case, tagging our images as latest is preferred since we want automatic deployments whenever a new webapp:latest reaches the registry. As you expect, tagging an existing image is a simple process:
docker image tag webapp hildenco.azurecr.io/webapp:latest

Then we push that image again just so our repo contains a latest tag to configure our webhook:

docker image push hildenco.azurecr.io/webapp:latest

We now should now see webapp:latest in our registry:

Enabling Continuous Deployment

With the requirements in place, let's configure the necessary settings to deploy whenever a new webapp:latest reaches the registry.

Enabling App Service Continuous Deployment

To enable continuous deployment for our App Service, open your App Service -> Container Settings, set Continuous Deployment to on and the tag to latest, then save:
This operation may take a little longer than you expect because it will create a webhook with the above configuration in our registry. See the next item for more information

Reviewing the Container Registry webhook

Now go to Container Registry -> Webhooks to confirm that the previous operation created a webhook for us. As seen from the history, it was never triggered so let's push a new image to test it.

Preparing a new Version

So let's prepare another version to test if our CD works. On this step we will change the code, rebuild the image, tag it as latest and push it to our private repo.
Keep track of your versions. Images can contain multiple tags and they don't occupy any space. Treat your tags as releases. In case you want to restore or redeploy an older version, it's easier to find them by tag and by image ID.

Changing the Source Code

Firstly let's change our super-complexcode and add a link to this site in our landing page:

Rebuilding the Image

Next, we rebuild our webapp with:
docker image build . -t webapp
Then we tag it with the registry's FQDN with:
docker image tag webapp hildenco.azurecr.io/webapp:latest

Testing our Continuous Deployment

With our local image ready and tagged, let's push it to our registry and verify if the webhook was triggered.

Pushing our Image

In order to push our image, login to ACR with:
az acr login -n hildenco
Then we push it with:
docker image push hildenco.azurecr.io/webapp:latest

Reviewing the webhook

Refresh the webhook page and see that the hook executed successfully:

Reviewing the logs

And on the logs tab under Container settings, I also see that the webhook was triggered (UTC time):

Reviewing the App

Lastly, we can confirm that our awesome app was updated on the public URL:

Conclusion

On this post we reviewed how to do continuous integration from Docker containers into our Azure App Services using our private Azure Container Registry. Docker containers today are the standard way to build, pack and ship our applications and it's important to learn how tools such as private container registries can help us be more effective.

References

See Also 

Posted by
Labels: , , , , , , , , , ,

Tuesday, February 2, 2021

Deploying Docker images to Azure App Services

Deploying Docker images to Azure App Services is simple. Learn how to deploy your Docker images to Azure App Services using Azure Container Registry (ACR)
Photo by Glenn Carstens-Peters on Unsplash

We've been discussing Docker, containers and microservices for some time on the blog. On previous posts we learned how to create our own ASP.NET Docker images and how to push them to Azure Container Registry. Today we'll learn how to deploy these same Docker images on Azure App Services.

On this post we will:

Requirements

As requirements, please make sure you have:
If you want to follow along, please check the previous tutorials discussing how to:

    About Azure App Services

    Azure developers are quite familiar with Azure App Services. But for those who don't know, App services are:
    HTTP-based services for hosting web applications, REST APIs, and mobile back ends. You can develop in your favorite language, be it .NET, .NET Core, Java, Ruby, Node.js, PHP, or Python. Applications run and scale with ease on both Windows and Linux-based environments.

    Why use App Services

    And why use Azure App Services? Essentially because App Services:
    • support multiple languages and frameworks: such as ASP.NET, Java, Ruby, Python and Node.js
    • can be easily plugged into your CI/CD pipelines, for example to deploy from Docker Hub or Azure Container Registries
    • can be used as serverless services
    • runs webjobs allowing us to deploy backend services without any additional costs
    • have a very powerful and intuitive admin interface 
    • are integrated with other Azure services

    Creating our App Service

    So let's get started and create our App Service. While this shouldn't be new to anyone, I'd like to review the workflow so readers understand the step-by-step. To create your App Service, in Azure, click Create -> App Service:
    On this screen, make sure you select:
    • Publish: Docker Container
    • OS: Linux

    Select the free plan

    Click on Change Plan to choose the free one (by default you're set on a paid one). Click Dev/Test and select F1:

    Selecting Docker Container/Linux

    Review the info and don't forget to select Docker Container/Linux for Publish and Operating System:

    Specifying Container Information

    Next, we specify the container information. On this step we will choose:
    • Options: Single Container
    • Image Source: Azure Container Registry
    • Registry: Choose yours
    Change Image Source to Azure Container Registry:
    On this step, Azure should auto-populate your repository. However, if you do not have admin user enabled (I didn't), you'll get this error:

    Enabling Admin in your Azure Container Registry

    To enable admin access to your registry, open it using the portal and on the Identity tab, change from Disable:
    To Enable and Azure will auto-generate the credentials for you:

    Specify your Container

    Back to the creation screen, as soon as the admin access is enabled on your registry, Azure should auto-populate the required information with your registry, image and tag (if one exists):
    Startup Command allows you to specify additional commands for the image (for example environment vars, volumes, configurations, etc).

    Review and Confirm

    Review and confirm. The deployment should take less than 1 second:

    Accessing our App Service in Azure

    As seen above, as soon as confirm, the deployment starts. It shouldn't take more than 1 minute to have it complete.

    Accessing our Web Application

    Let's check if our image is running. From the above image you can see my image's URL highlighted in yellow. Open that on a browser to confirm the site is accessible:

    Container Features

    To finish, let's summarize some features that Azure offers us to easily manage our containers. 

    Container Settings

    Azure still offers a Container Settings tab that allows us to inspect, change container settings for our web app.

    Container Logs

    We can inspect logs for our containers to easily troubleshoot them.
    As an example, here's an excerpt of what I got for my own container log:
    2020-04-10 04:32:51.913 INFO  -  Status: Downloaded newer image for hildenco.azurecr.io/webapp:v1
    2020-04-10 04:32:52.548 INFO  - Pull Image successful, Time taken: 0 Minutes and 47 Seconds
    2020-04-10 04:32:52.627 INFO  - Starting container for site
    2020-04-10 04:32:52.627 INFO  - docker run -d -p 5021:80 --name hildenco-docker_0_e1384f56 -e WEBSITES_ENABLE_APP_SERVICE_STORAGE=false -e WEBSITE_SITE_NAME=hildenco-docker -e WEBSITE_AUTH_ENABLED=False -e PORT=80 -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_HOSTNAME=hildenco-docker.azurewebsites.net -e WEBSITE_INSTANCE_ID=[redacted] hildenco.azurecr.io/webapp:v1 
    2020-04-10 04:32:52.627 INFO  - Logging is not enabled for this container.
    Please use https://aka.ms/linux-diagnostics to enable logging to see container logs here.
    2020-04-10 04:32:57.601 INFO  - Initiating warmup request to container hildenco-docker_0_e1384f56 for site hildenco-docker
    2020-04-10 04:33:02.177 INFO  - Container hildenco-docker_0_e1384f56 for site hildenco-docker initialized successfully and is ready to serve requests.

    Continuous Deployment (CD)

    Another excellent feature that you should explore in the future is enabling continuous deployment on your web apps. Enabling continuous deployment is essential to help your team gain agility by releasing faster and often. We'll try to cover this fantastic topic in the future, keep tuned.

    Conclusion

    On this post we reviewed how to create an Azure App Service and learned how to deploy our own Docker Images from our very own Azure Container Registry (ACR) to it. By using ACR greatly simplified the integration between our own Docker Images and our App Services. From here I'd urge you to explore continuous integration to automatically push your images to your App Services as code lands in your git repository.

    References

    See Also

    Posted by
    Labels: , , , , , , , , , , , ,

    About the Author

    Bruno Hildenbrand