Home Blog Page 115

How we saved days of work with IT automation: A case study

How we saved days of work with IT automation: A case study

Automation made our team’s everyday tasks go from days to minutes and made us more efficient in disaster-recovery situations.
Kedar Vijay Kulkarni
Fri, 5/28/2021 at 8:03pm

Image

Image by pasja1000 from Pixabay

In 2020, I was working on a team automating the process of creating new virtual machine (VM) images for the latest Red Hat Satellite builds. Our goal was to automate VM deployments, snapshots, cleanup, and template creation. It sounds easy, but it was a lot of work. Automation was obviously needed to save time for our team, and we picked Red Hat Ansible Automation Platform as the automation interface. That’s where this story begins.

Topics:  
Automation  
Ansible  

Read More at Enable Sysadmin

How we saved days of work with IT automation: A case study

Automation made our team’s everyday tasks go from days to minutes and made us more efficient in disaster-recovery situations.

Read More at Enable Sysadmin

Will IT automation kill my job?

What do you do after you automate all your mundane, repeatable tasks?

Read More at Enable Sysadmin

6 troubleshooting skills for Ansible playbooks

6 troubleshooting skills for Ansible playbooks

Here are six ways you can check for problems when running Ansible playbooks.
Roberto Nozaki
Wed, 5/26/2021 at 9:11pm

Image

Image by StockSnap from Pixabay

Ansible is a very powerful tool that allows you to automate a huge variety of platforms across servers, clouds, networks, containers, and more.

Often you will be able to automate what you want by simply reusing existing roles and collections.

Topics:  
Linux  
Linux Administration  
Ansible  
Troubleshooting  
Read More at Enable Sysadmin

Build and Deploy Hyperledger Fabric on Azure Cloud Platform- Part 1

By Matt Zand and Abhik Banerjee

Here is an outline of topics covered in this article series:

Azure cloud for Blockchain Applications
Fabric Marketplace Template versus Manual Configurations
Deploy Orderer and Peer Organizations
Setting Up the Development Environment
Setting Up Configurations for Orderer and Peer
Setting Up Pods and Volume Mounts for Development
Create A Channel
Adding  Peer to Network, Channel and Nodes
Deploying and Operating Chaincode

This series is divided into 3 parts: 

In the first part, we cover item 1, 2, 3 of the outline. In the second part, we will cover items 4, 5 and 6 and in the last part we will cover the remaining items (7, 8 and 9). 

Introduction

By finishing this article series, you will gain and be able to put Hyperledger Fabric skills into practice through creating and deploying Fabric applications on Azure cloud platforms. As such, this article covers highly practical steps for those interested in moving their Fabric application from the pilot step to production. We start off by reviewing the Azure cloud platform and its features, and follow with hands-on steps for building and deploying Fabric applications on Azure. 

While managed blockchain solutions from Azure were limited to an enterprise Ethereum variant called Quorum, Hyperledger Fabric is now also supported. However, at the time of writing, Azure Blockchain Service only offers Quorum in General Availability. Support for Hyperledger Fabric is a part of offering Blockchain-As-A-Service (BAAS) solutions in the Azure platform..

It should be noted that while this article is intended to be beginner friendly, it would be helpful to have prior familiarity with Azure, Kubernetes APIs, and Azure Kubernetes Service (AKS). Also, a good knowledge of Hyperledger Fabric and its components is required to follow steps discussed in this article. If you have no experience with Fabric, The Linux Foundation’s free Introduction to Hyperledger Blockchain Technologies course is a good place to start. The topics and steps covered in this article are very useful for those interested in doing blockchain consulting and development.

1- Azure Cloud for Blockchain Applications

Before we dive head first into building a blockchain network on Azure, it would be beneficial to look at the three main blockchain options provided by Microsoft Azure. These are:

Azure Blockchain Service (ABS) 

Azure Blockchain Service is a managed service from Microsoft Azure that aims to help organizations get started quickly with their blockchain solutions. It manages the deployment of Validator and Transaction Nodes in the network and can be easily used from the Azure Portal itself. 

Azure Blockchain Workbench (ABW)

Azure Blockchain Workbench takes the whole “managed” paradigm to another level. It introduces managed identity elements in the network. The participants in the network can have their addresses managed with the Azure Active Directory (AD). ABW also offers easy integration with Azure Services like Cosmos Database for storing off-chain data for analytics. However, like ABS, this too only supports Quorum at this time. Azure Blockchain Workbench is in “public preview” and can be a great way to test out Proof of Concepts quickly.

Azure Resource Manager Templates (ARM Templates)

Azure Resource Manager (ARM) can be thought of as a creator and a shepherd for your Microsoft Azure Resources. It is as simple as handing a JSON object to ARM. ARM Templates are basically JSON files that contain details of the infrastructure you might want to deploy (say a VM with 3 vCores and 100 GB of SSD storage and CentOS). ARM takes in these templates and then provisions said resources as you want them. In our case, Azure Marketplace is where one can find the ARM Template for deploying Hyperledger Fabric on Azure. Azure Marketplace provides the option to use ARM Template for deploying Hyperledger Fabric Nodes using AKS. Azure makes it easier by allowing the option to deploy from the Azure Portal itself. The deployed nodes exist in an AKS cluster and can be managed from the portal, Azure Shell or command line or even your local PC through kubectl (Kubernetes control CLI). We will be going with the latter solution in this section.

In the following sections we briefly compare the marketplace template with AKS using manual configurations and then dive into a hands-on Hyperledger Fabric network deployment on Azure, while playing around with a custom chaincode on the deployed solution.

2- Fabric Marketplace Template versus Manual Configurations

Azure Marketplace is a great place to find pre-built solutions. In our case, we are looking for a particular solution named “Hyperledger Fabric on Azure Kubernetes Service”. Before we discuss using it, let’s explore why someone may prefer it over manually provisioning their own resources. 

Manual provisioning can be helpful when one cannot find the proper base to build their solution. However, it requires in-depth knowledge of the platform. This is true not only for Azure but for anything. If there is a need for manual configuration, the architect needs to have a thorough understanding of networking, security and compliance on Azure. By this we mean that the person who will configure the network manually needs to know how to put up VMs and link them in a network without making the resources like SSH Keys or storage open to attacks.

For this reason, it is better to follow Murphy’s Law – “if something can go wrong, it will”. If so,  wouldn’t it be better to let aspects of the network be handled by Azure itself? This would also help the blockchain developer/operator improve their use case and focus on the chaincode, Access Control Lists, Fabric network architecture, and peer policies. This also does not close off the path of managing nodes in the network manually as an outside node, regardless of the cloud platform it is running on, can be a participant in the Hyperledger Fabric Network deployed on Azure.

3- Deploy Orderer and Peer Organizations

To begin, open your Azure Portal and then click on “Create a Resource” (the big + sign) which will take you to Azure Marketplace. From the list on the left find the option titled “Blockchain”. Once you click on it, you will see options like “Azure Blockchain Service”, “Azure Blockchain Workbench”, “Ethereum Studio” and more.  Click on “Hyperledger Fabric on Azure Kubernetes Service”.

At this point you might want to have a pre-created Azure Service Principal. Service Principals are needed for deploying Kubernetes (K8s) clusters on Azure. The logic behind this is – you cannot do anything in Azure without permissions! But instead of attaching permissions to your person, you have service principals. The permissions to create a K8s node in Azure, for example, gets attached to this service principal along with any other required permissions. Every time you want to deploy an AKS cluster you get to use this service principal. 

Hint

Service principals are complex and important, with many best practices to consider. Since this is outside the scope of this article, we will focus on Fabric on AKS.

Someone who uses Azure regularly might ask “Doesn’t AKS automatically create a service principal  for me?” Normally, it does but this is an exception; you can easily create a service principal if you don’t have one already by running the following command in the Azure CLI:

az ad sp create-for-rbac –skip-assignment –name {Name of the Service Principal}

Once you run this, you will get the output which will give you an App ID and a Password among other things. These are the ones which you will need here.

Now let’s deploy an orderer node using the portal. In the first screen you’ll see the following options:

Subscription 

Select the subscription you would like to use at this time. 

Resource Group 

An Azure Resource Group is a handy way to keep multiple resources in the same “basket” so to speak. These can be categorized based on resource type (say one RG for compute resources like VMs, another for storage) or by solution/use case. In our case, we will create two resource groups–one for Orderer and another for Org01 resources. Click on “Create New” and enter your resource group name (here we go with RG-HLF-AzureOrderer).

Region 

The Azure Region you want to deploy your resources to. Here we go with the default Central US.

Resource Prefix 

This is a collection of at most 6 characters that would be prepended to the resources being provisioned by/for this AKS cluster. We use the prefix “order” here to denote that the resources belong to Orderer Service.

Click on “Next : Fabric settings >” to set your Hyperledger Fabric related information. Here you would be asked to fill the following details:

Organization Name 

This would be the name of the organization trying to join the network. As you may know by now, a Hyperledger Fabric network is always brought up with an Orderer at first. Following suit here we shall name it “OrdererOrg”.

Fabric network component: 

Next you select the type of service. This is a drop-down menu where you get to select from “Ordering Service” and “Peer Node”. We shall select it as “Ordering Service”.

Number of nodes 

If you select the above option as Ordering Service, you need to choose between having 3, 5, or 7 nodes. Since this is a demo, we are going with 3. (You may be wondering why the choices are like this; this is to get the number of ordering nodes in a number conformable with the Consensus Protocol).

Fabric CA username 

Certifying Authority is one of the central parts of the network. Without a CA, you cannot enroll new members or sign transactions which would be considered from a valid identity. Here we select the username as “ordca01”.

Fabric CA password 

Now you need to select a secure password to go with your CA username. Confirm this in the next option.

Certificates 

You get a choice of selecting between self-signed certificates which would be managed automatically or to upload your own custom ones to act for the Fabric Certifying Authority. Here we choose the managed option – “Fabric CA self-signed certificates”.

After deciding on your HF network specific parameters for Ordering Service, you need to select the settings for the AKS Cluster to which it will be deployed. We leave most of the options at this screen as defaults. The ones which might require attention are Node Size (the type of Azure VMs to use in your cluster), Node Count and the service principal related fields Service principal client ID, Service principal client secret, and Azure Monitor

Keep in mind the following:

The Node type you select at this stage will directly impact the cost of sustaining your HF Network.
Do not change the Node Count here. It has to be selected in the previous screen and it plays an important part in the consensus.
If you already have a service principal, you may use it to deploy this cluster. Otherwise refer to the beginning of this section on how to create one. Put in the service principal’s app ID and password in the respective fields.
You may choose to enable cluster wide monitoring with Azure Monitor (in fact it’s recommended that you do). This will help you analyze metrics like transaction count and rate of memory growth.

Deploy your Orderer Service Cluster on AKS. It should take about 10-15 minutes for the cluster to deploy. Meanwhile we can complete another important step – create a cluster for our organization which would be a part of this network. Most of the steps in this case would be the same as above. We will be starting again from the “Hyperledger Fabric on Azure Kubernetes Service” template in Azure Marketplace and then going over the same steps. The values which may differ in this case are listed in the below table. 

Field
Value

Resource Group
RG-HLF-AzureOrg (creating another new RG for peer)

Resource prefix
org01 (for identifying all resources belonging to peer Org01)

Organization Name
Org01

Fabric network component
Peer nodes

Number of nodes
1 (can vary depending on your budget)

Peer node world state database
CouchDB

Fabric CA username
orgca01

Here we get an option to select between CouchDB and LevelDB. These two are natively offered from Hyperledger Fabric at this time. We go with CouchDB. Feel free to read up on the difference between the two if you are interested.

Now we have our clusters for Ordering Service and a sample organization Org01 in deployments and these will be up and running in a few moments. We have covered some ground, so let’s reflect on our future course of action – we have clusters for Orderers and Organization and now we need to create a network out of these two. We also need to create a channel where OrdererOrg will function as the ordering service and we need Org01 to join first and then record the nodes owned by it (basically the nodes in that cluster). While doing all this, we also need to set up a development environment which would provide common ground to develop from within the respective clusters as well as from outside clusters. We will do all these in the next article in the series.

Summary

We finished the first part of our article series where we discussed the Azure cloud platform offering for blockchain development as well as differences between Azure marketplace template and manual configuration. We also take our first step toward building Hyperledger Fabric blockchain applications on Azure by deploying Orderer and peer Organization. 

In our next article in this series, we will cover how to set up the development environment, configure the Orderer and peer, and set pods and volume mounts for our Fabric application. 

Resources

Free Training Courses from The Linux Foundation & Hyperledger

Blockchain: Understanding Its Uses and Implications (LFS170)
Introduction to Hyperledger Blockchain Technologies (LFS171)
Introduction to Hyperledger Sovereign Identity Blockchain Solutions: Indy, Aries & Ursa (LFS172)
Becoming a Hyperledger Aries Developer (LFS173)
Hyperledger Sawtooth for Application Developers (LFS174)

eLearning Courses from The Linux Foundation & Hyperledger

Hyperledger Fabric Administration (LFS272)
Hyperledger Fabric for Developers (LFD272)

Certification Exams from The Linux Foundation & Hyperledger

Certified Hyperledger Fabric Administrator (CHFA)
Certified Hyperledger Fabric Developer (CHFD)

Review of Five popular Hyperledger DLTs- Fabric, Besu, Sawtooth, Iroha and Indy
Review of three Hyperledger Tools- Caliper, Cello and Avalon
Review of Four Hyperledger Libraries- Aries, Quilt, Ursa, and Transact

Hands-On Smart Contract Development with Hyperledger Fabric V2 Book by Matt Zand and others.
Essential Hyperledger Sawtooth Features for Enterprise Blockchain Developers
Blockchain Developer Guide- How to Install Hyperledger Fabric on AWS
Blockchain Developer Guide- How to Install and work with Hyperledger Sawtooth
Intro to Blockchain Cybersecurity (Coding Bootcamps)
Intro to Hyperledger Sawtooth for System Admins (Coding Bootcamps)
Blockchain Developer Guide- How to Install Hyperledger Iroha on AWS
Blockchain Developer Guide- How to Install Hyperledger Indy and Indy CLI on AWS
Blockchain Developer Guide- How to Configure Hyperledger Sawtooth Validator and REST API on AWS
Intro blockchain development with Hyperledger Fabric (Coding Bootcamps)
How to build DApps with Hyperledger Fabric
Blockchain Developer Guide- How to Build Transaction Processor as a Service and Python Egg for Hyperledger Sawtooth
Blockchain Developer Guide- How to Create Cryptocurrency Using Hyperledger Iroha CLI
Blockchain Developer Guide- How to Explore Hyperledger Indy Command Line Interface
Blockchain Developer Guide- Comprehensive Blockchain Hyperledger Developer Guide from Beginner to Advance Level
Blockchain Management in Hyperledger for System Admins
Hyperledger Fabric for Developers (Coding Bootcamps)
Free White Papers from Hyperledger
Free Webinars from Hyperledger
Hyperledger Wiki

About the Authors

Matt Zand is a serial entrepreneur and the founder of 4 tech startups: DC Web Makers, Hash Flow, Coding Bootcamps and High School Technology Services. He is a leading author of Hands-on Smart Contract Development with Hyperledger Fabric book by O’Reilly Media. He has written more than 100 technical articles and tutorials on blockchain development for Hyperledger, Ethereum and Corda R3 platforms at sites such as IBM, SAP, Alibaba Cloud, Hyperledger, The Linux Foundation, and more. At Hash Flow, he leads a team of blockchain experts for consulting and deploying enterprise decentralized applications. As chief architect, he has designed and developed blockchain courses and training programs for Coding Bootcamps. He has a master’s degree in business management from the University of Maryland. Prior to blockchain development and consulting, he worked as senior web and mobile App developer and consultant, investor, business advisor for a few startup companies. You can connect with him on LI: https://www.linkedin.com/in/matt-zand-64047871

Abhik Banerjee is a researcher, an avid reader and also an anime fan. In his free time you can find him reading whitepapers and building hobby projects ranging from DLT to Cloud Infra. He has multiple publications in International Conferences and Book Titles along with a couple of patents in Blockchain. His interests include Blockchain, Quantum Information Processing and Bioinformatics. You can connect with him on LI:  https://in.linkedin.com/in/abhik-banerjee-591081164

The post Build and Deploy Hyperledger Fabric on Azure Cloud Platform- Part 1 appeared first on Linux Foundation – Training.

New container feature: Volatile overlay mounts

With containers, we don’t always care about data being retained after a crash. See how volatile overlay mounts can help increase performance in these situations.
Read More at Enable Sysadmin

The Linux Foundation joins Accenture, GitHub, Microsoft, and ThoughtWorks to Launch the Green Software Foundation to put sustainability at the core of software engineering

As we think about the future of the software industry, we believe we have a responsibility to help build a better future – a more sustainable future – both internally at our organizations and in partnership with industry leaders around the globe. With data centers around the world accounting for 1% of global electricity demand, and projections to consume 3-8% in the next decade, it’s imperative we address this as an industry.

To help in that endeavor, we’re excited to announce the formation of The Green Software Foundation – a nonprofit founded by Accenture, GitHub, Microsoft, and ThoughtWorks established with the Linux Foundation and the Joint Development Foundation Projects LLC to build a trusted ecosystem of people, standards, tooling, and leading practices for building green software.

Read more at The Microsoft Blog

The post The Linux Foundation joins Accenture, GitHub, Microsoft, and ThoughtWorks to Launch the Green Software Foundation to put sustainability at the core of software engineering appeared first on Linux Foundation.

SPDX: It’s Already in Use for Global Software Bill of Materials (SBOM) and Supply Chain Security

Author: Kate Stewart, VP of Dependable Systems, The Linux Foundation

In a previous Linux Foundation blog, David A. Wheeler, director of LF Supply Chain Security, discussed how capabilities built by Linux Foundation communities can be used to address the software supply chain security requirements set by the US Executive Order on Cybersecurity. 

One of those capabilities, SPDX, completely addresses the Executive Order 4(e) and 4(f) and 10(j) requirements for a Software Bill of Materials (SBOM). The SPDX specification is implemented as a file format that identifies the software components within a larger piece of computer software and metadata such as the licenses of those components. 

SPDX is an open standard for communicating software bill of material (SBOM) information, including components, licenses, copyrights, and security references. It has a rich ecosystem of existing tools that provides a common format for companies and communities to share important data to streamline and improve the identification and monitoring of software.

SBOMs have numerous use cases. They have frequently been used in areas such as license compliance but are equally useful in security, export control, and broader processes such as mergers and acquisitions (M&A) processes or venture capital investments. SDPX maintains an active community to support various uses, modeling its governance and activity on the same format that has successfully supported open source software projects over the past three decades.

The LF has been developing and refining SPDX for over ten years and has seen extensive uptake by companies and projects in the software industry.  Notable recent examples are the contributions by companies such as Hitachi, Fujitsu, and Toshiba in furthering the standard via optional profiles like “SPDX Lite” in the SPDX 2.2 specification release and in support of the SPDX SBOMs in proprietary and open source automation solutions. 

This de facto standard has been submitted to ISO via the Joint Development Foundation using the PAS Transposition process of Joint Technical Committee 1 (JTC1). It is currently in the enquiry phase of the process and can be reviewed on the ISO website as ISO/IEC DIS 5962.

There is a wide range of open source tooling, as well as commercial tool options emerging as well as options available today.  Companies such as FOSSID and Synopsys have been working with the SPDX format for several years. Open Source tools like FOSSology (source code Analysis),  OSS Review Toolkit (Generation from CI & Build infrastructure), Tern (container content analysis), Quartermaster (build extensions), ScanCode (source code analysis) in addition to the SPDX-tools project have also standardized on using SPDX for the interchange are also participating in Automated Compliance Tooling (ACT) Project Umbrella.  ACT has been discussed as community-driven solutions for software supply chain security remediation as part of our synopsis of the findings in the Vulnerabilities in the Core study, which was published by the Linux Foundation and Harvard University LISH in February of 2020.   

One thing is clear: A software bill of materials that can be shared without friction between different teams and companies will be a core part of software development and deployment in this coming decade. The sharing of software metadata will take different forms, including manual and automated reviews, but the core structures will remain the same. 

Standardization in this field, as in others, is the key to success. This domain has an advantage in that we are benefiting from an entire decade of prior work in SPDX. Therefore the process becomes the implementation of this standard to the various domains rather than the creation, expansion, or additional refinement of new or budding approaches to the matter.

Start using the SPDX specification here:https://spdx.github.io/spdx-spec/. Development of the next revision is underway, so If there’s a use case you can’t represent with the current specification, open an issue, this is the right window for input.   

To learn more about the many facets of the SPDX project see: https://spdx.dev/

The post SPDX: It’s Already in Use for Global Software Bill of Materials (SBOM) and Supply Chain Security appeared first on Linux Foundation.

Oracle Ampere A1 Compute tuning for advanced users

Advanced tuning techniques for Oracle Ampere A1 instances
Click to Read More at Oracle Linux Kernel Development

Oracle Ampere A1 Compute tuning for advanced users

Advanced tuning techniques for Oracle Ampere A1 instances.

Click to Read More at Oracle Linux Kernel Development