You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: learn-pr/advocates/intro-azure-arc-enabled-vmware-vsphere/includes/1-azure-arc-enabled-vmware.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,6 +13,8 @@ To connect your VMware vCenter Server to Azure Arc, you need to deploy the Azure
13
13
14
14
vSphere resources are automatically discovered when you connect a VMware vCenter Server to Azure. After initial discovery, regular synchronization between the vCenter Server and Azure ensures that this inventory data is kept up-to-date.
15
15
16
+
[](../media/arc-vmware-architecture.png#lightbox)
17
+
16
18
Guest OS-based capabilities are provided by enabling guest management. Guest management involves installing the Arc agent on the VMs running in the VMware environment. Once you enable guest management, you can deploy VM extensions to extend the Azure management capabilities. For example, by enabling guest management, you can perform virtual hardware operations such as VM resizing, adding and deleting disks, and VM restarts.
17
19
18
20
Arc-enabled VMware vSphere works with vCenter Server versions 7 and 8. You can onboard multiple vCenters using a single Azure Arc resource bridge as long as the total number of VMs managed across all onboarded systems doesn't exceed 9500.
Copy file name to clipboardExpand all lines: learn-pr/advocates/intro-azure-arc-enabled-vmware-vsphere/includes/3-azure-arc-enabled-vmware-vm-operations.md
+4Lines changed: 4 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -32,6 +32,8 @@ When the Azure Connected Machine agent is installed on vCenter-managed VMs, Admi
32
32
- Monitor operating system performance and discover application components to monitor processes and dependencies with other resources using VM insights.
33
33
- Collect other log data, such as performance data and events, from the operating system or workloads running on the machine with the Azure Monitor Agent.
34
34
35
+
[](../media/connected-machine-agent.png#lightbox)
36
+
35
37
The Azure Connected Machine agent is updated regularly to address bug fixes, stability enhancements, and new functionality. Azure Advisor identifies resources that aren't using the latest version of the machine agent and recommends that you upgrade to the latest version. It notifies you when you select the Azure Arc-enabled server by presenting a banner on the Overview page, or when you access Advisor through the Azure portal.
36
38
37
39
The Azure Connected Machine agent for Windows and Linux can be upgraded to the latest release manually or automatically, depending on your requirements. Installing, upgrading, or uninstalling the Azure Connected Machine Agent doesn't require you to restart your server.
@@ -96,3 +98,5 @@ For SQL Server environments that run in a VM in Azure VMware Solution, you can u
96
98
- ESU subscription
97
99
- Automated patching
98
100
1. Select Subscribe to Extended Security Updates. It sets the host configuration property EnableExtendedSecurityUpdates to True. The subscription is activated after you select Save.
101
+
102
+
[](../media/azure-portal-sql.png#lightbox)
Copy file name to clipboardExpand all lines: learn-pr/cmu-cloud-admin/cmu-cloud-security/includes/4-data-security.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@ Data stored in the cloud must only be accessible through legitimate sources that
6
6
7
7
Because absolute security is never ensured, most organizations safeguard data stored in the cloud using a multilayered security strategy sometimes referred to as *defense in depth*. The core principle is that if an attacker penetrates one of your defenses, the next defense may be the one that stops them. A multilayered security strategy also provides protection against different and potentially unrelated attack vectors. For example, protecting a database with IAM so that only designated users can access it through a cloud portal does nothing to protect the database if an attacker gains access to the server that hosts the database and makes a copy of the database files. Going the extra step of encrypting those files, however, would.
8
8
9
-
Figure 4 illustrates how multilayered security for a cloud database might be structured. The data is encrypted in place ("encrypted at rest") and encrypted with TLS when it travels over the wire ("encrypted in motion"). Outside that is a layer that logs all accesses to the data so that an audit trail is maintained. This layer may also host an active threat-detection agent that continually monitors accesses to the database and alerts administrators to suspicious activity. The next layer uses IAM to make sure only authorized users and applications can connect to the database. Finally, the outermost layer restricts accesses to the database over the network. For example, it might specify that the database can only be accessed from a certain VNet or set of VNets, and it may restrict connections from the outside to a white-listed set of IP addresses.
9
+
Figure 4 illustrates how multilayered security for a cloud database might be structured. The data is encrypted in place ("encrypted at rest") and encrypted with TLS when it travels over the wire ("encrypted in motion"). Outside that is a layer that logs all accesses to the data so that an audit trail is maintained. This layer may also host an active threat-detection agent that continually monitors accesses to the database and alerts administrators to suspicious activity. The next layer uses IAM to make sure only authorized users and applications can connect to the database. Finally, the outermost layer restricts accesses to the database over the network. For example, it might specify that the database can only be accessed from a certain VNet or set of VNets, and it may restrict connections from the outside to an allowlisted set of IP addresses.
10
10
11
11

Copy file name to clipboardExpand all lines: learn-pr/cmu-cloud-admin/cmu-orchestration/includes/4-infrastructure-as-code-tools.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,9 +15,9 @@ The choice that enterprises make when choosing a CM platform, and an Infrastruct
15
15
16
16
## Azure Resource Manager templates
17
17
18
-
Microsoft's Azure Resource Manager template system is a tool for generating an explicit specification for one or more cloud resources. An Azure Resource Manager template is designed to be a complete inventory of the values and parameters needed to execute Azure instructions for provisioning new resources and updating existing ones. This inventory is expressed in JSON, a format that has become almost ubiquitous in software development. Azure Resource Manager templates are exclusive to Azure and cannot specify resources for a multi-cloud infrastructure.
18
+
Microsoft's Azure Resource Manager template system is a tool for generating an explicit specification for one or more cloud resources. An Azure Resource Manager template is designed to be a complete inventory of the values and parameters needed to execute Azure instructions for provisioning new resources and updating existing ones. This inventory is expressed in JSON, a format that has become almost ubiquitous in software development. Azure Resource Manager templates are exclusive to Azure and can't specify resources for a multicloud infrastructure.
19
19
20
-
Azure Resource Manager templates can be generated by hand, but more often they are generated (and edited) through the Azure portal or using tools such as Visual Studio and Visual Studio Code. Figure 4 shows a template for provisioning an Azure storage account. The template includes the following sections:
20
+
Azure Resource Manager templates can be generated by hand, but more often they're generated (and edited) through the Azure portal or using tools such as Visual Studio and Visual Studio Code. Figure 4 shows a template for provisioning an Azure storage account. The template includes the following sections:
21
21
22
22
- A **parameters** section defining parameter values such as the storage-account name that the user will enter when the template is executed, as well as optional default values and allowed values
23
23
@@ -84,7 +84,7 @@ In short, what a script in another configuration manager would seek to define an
84
84
85
85
Puppet manages the configuration of resources and services across a cluster of servers through a central controller node called the *master* that is backed up by replicates. As its name implies, the Puppet platform establishes a master/agent relationship between central nodes and a variable number of client nodes where Puppet *agents* are installed.
86
86
87
-
Rather than use JSON as Azure Resource Manager templates do, Puppet uses instructions inspired by the Ruby programming language in which it was originally written. A set of instructions for Puppet that represents an infrastructure-management task (for example, provisioning a server with Linux, MySQL, and other components of a LAMP stack) is represented by a *module*, which is actually a directory containing several files in a certain structure. The most important of these files is the *manifest*, which is written in a domain-specific language (DSL) unique to Puppet. This DSL is not technically a programming language because it does not state the steps an interpreter or processor must take to accomplish a task.
87
+
Rather than use JSON as Azure Resource Manager templates do, Puppet uses instructions inspired by the Ruby programming language in which it was originally written. A set of instructions for Puppet that represents an infrastructure-management task (for example, provisioning a server with Linux, MySQL, and other components of a LAMP stack) is represented by a *module*, which is actually a directory containing several files in a certain structure. The most important of these files is the *manifest*, which is written in a domain-specific language (DSL) unique to Puppet. This DSL isn't technically a programming language because it doesn't state the steps an interpreter or processor must take to accomplish a task.
88
88
89
89
As Figure 6 illustrates, the architecture of a system running the Puppet platform is surprisingly unsophisticated. A node in Puppet, like a node in Kubernetes or in OpenStack, is a server --- a physical or a virtual one, but a participant in the collective platform. There are master nodes and agent nodes. Those servers that the master manages have active agents installed on them. Communication takes place through SSH channels. Typically, these channels are secured through a local subnet that is closed to the outside Internet. Modules for Puppet instructions may be stored in, and retrieved from, a repository, although that connection doesn't need be private, and Puppet itself doesn't recognize the repository as an agent or a node.
90
90
@@ -104,13 +104,13 @@ Many metaphors in Chef are based around cooking. A Chef script is called a *reci
104
104
105
105
Unlike Puppet, a Chef recipe is a program that is tested, refined, and then preserved. However, the way it's written is somewhat more abstract than any of the system-dependent scripts seen earlier. Its use of Ruby is more symbolic, with Knife capable of translating abstract instructions into specifics. These instructions are not declarations like in Puppet, or statements of goals, objectives, or desired states, but rather imperative commands. For example, server nodes in a data center may each have different distributions of Linux installed. A recipe may instruct Knife to figure out which Linux version is installed on a node, and in a conditional clause, state which edition of a package is most appropriate for that version. It may also make adjustments to that package's local configuration file.
106
106
107
-
The instructions from Chef to Knife are explicit. Chef is about defining, and then refining, the methods by which a working version of a solution is attained and maintained. Continual refinement is still possible; sequences of instructions don't have to be set in stone, as they often are with stand-alone scripts. But at least there is a methodology to guide the way. It can be deliberate without breaking existing processes, especially if those processes --- or to be more specific, their recipes --- are built to be resilient, and to test for whether certain conditions have changed before committing important alterations to configurations. That said, Chef has had evolutionary upgrades over the years that have necessitated structural changes to its own recipes.
107
+
The instructions from Chef to Knife are explicit. Chef is about defining, and then refining, the methods by which a working version of a solution is attained and maintained. Continual refinement is still possible; sequences of instructions don't have to be set in stone, as they often are with stand-alone scripts. But at least there's a methodology to guide the way. It can be deliberate without breaking existing processes, especially if those processes --- or to be more specific, their recipes --- are built to be resilient, and to test for whether certain conditions have changed before committing important alterations to configurations. That said, Chef has had evolutionary upgrades over the years that have necessitated structural changes to its own recipes.
108
108
109
109
## Red Hat Ansible
110
110
111
-
Ansible is a CM tool that shares some traits with Puppet, although it also subscribes to the notion of a complete inventory list, like Azure Resource Manager templates. Its goal is to produce a single script that installs, configures, and maintains a given service or application on any server infrastructure. It's based on the concept of *push configuration*. Unlike the situation with both Puppet and Chef, where client-side agents make requests for updated configurations from a master server, there are no remote agents in the Ansible system.
111
+
Ansible is a CM tool that shares some traits with Puppet, although it also subscribes to the notion of a complete inventory list, like Azure Resource Manager templates. Its goal is to produce a single script that installs, configures, and maintains a given service or application on any server infrastructure. It's based on the concept of *push configuration*. Unlike the situation with both Puppet and Chef, where client-side agents make requests for updated configurations from a central server, there are no remote agents in the Ansible system.
112
112
113
-
Configuration tasks for each node (not "clients" because there's no direct relationship between them and the server) are based around common *playbooks*. A playbook is actually a database, not an instructional script, containing the conditions that must be met for a configuration to be complete --- for example, for the components of a LAMP stack to be installed. The Ansible server adapts this playbook for each node's peculiarities and eccentricities, using its infrastructure inventory database as a guide.
113
+
Configuration tasks for each node (not "clients" because there's no direct relationship between them and the server) are based around common *playbooks*. A playbook is actually a database, not an instructional script, containing the conditions that must be met for a configuration to be complete ---, for example, for the components of a LAMP stack to be installed. The Ansible server adapts this playbook for each node's peculiarities and eccentricities, using its infrastructure inventory database as a guide.
114
114
115
115
Both the playbook and the inventory are written in YAML, a language originally created as an alternative to JSON for codifying data. Figure 8 shows a segment of a playbook from an open-source Ansible repository<sup>[1][^1]</sup> that sets up users for MySQL once its package has been installed. There's no instructional syntax, only keys and values. Since these values represent transitional states --- in this case, for each user in MySQL --- the Ansible server finds the best method for applying these changes to the roster of the system it's configuring. As some Ansible advocates have argued, this can be viewed as a kind of desired state configuration, so long as that state is something that can be expressed explicitly using YAML.
0 commit comments