In addition to its coverage of core Azure services, the book discusses common tools useful in creating and managing Azure-based solutions. The free premium eBook contains much more information regarding Azure Essentials so go ahead and download it from our personal server and let us know what you think in the comments. I love everything to do with Microsoft Windows, and the new Windows 10 is great so far. I love to spend my time researching on how viruses and bacteria work in my personal lab.
I also enjoy history and comics. Microsoft Launches Windows 10 November Update. How to Download the Windows 10 November Update. Microsoft Releases Windows 11 Build Best BitTorrent Clients for Windows Best Photoshop Alternatives for Windows Best Antivirus Software for Windows Best iTunes Alternatives for Windows You can preview your site here. It will open your web application in the default browser after it is published. When you make changes to your website, you can go through this same process to publish the website again.
Note that it will only publish the files that have been added or modified. Configuring Web Apps Log into the Azure portal and go to the web application you created and deployed from Visual Studio earlier. The primary blade should look like Figure This displays by default when you first open the Web App blade, and is the same blade you see when you click All Settings.
It also provides access to the Kudu console, which is helpful for troubleshooting and analysis. For example, if you have a production slot and a staging slot, you can publish your web app to staging and test it. These credentials are used for FTP and Git access.
Click Settings to open the Settings blade. There are links to install Visual Studio and the Microsoft Azure SDK, links to reset your deployment credentials, and links to tutorials, forums, samples, etc.
The top of the Application Settings blade shown in Figure lets you set things like the. NET application, this will denote the major version being used. Values available are 3. PHP 5. Java 7 and 8 are supported. For Python, versions 2. Note that you cannot select bit for Free websites. If you need your webpage to be live and active all of the time, set this to On. If set to On, you can then select which version of Visual Studio you want to use to perform the debugging.
Be sure to specify the Debug configuration when you publish your web app if you want to perform remote debugging. Other settings farther down this blade include the list of default documents, handler mappings, and virtual applications and directories.
These are the App Service plan settings you can configure on this blade. This will show the settings for that App Service plan, which are the same values you see if you choose your App Service plan from All Resources on the main menu of the Azure portal.
Each pricing tier provides different values for the number of cores, amount of memory, amount of storage, and so on. For example, you can ask it to increase the number of VMs if your CPU percentage reaches 90 percent and stays there for X number of minutes. For example, you can set one up and call it staging, then publish interim changes to it. Below the properties of the web app is a pane showing the default Monitoring.
You can click Edit in that pane to see all of the metrics you can add to that chart and set the time range to be displayed and the type of chart Figure This shows overall metrics for your web app as well as metrics for each instance that is running.
You can ask to see the last 24 hours, the last hour, or the last 5 days. This is graphed for you. This has the same settings as the option for your site 24 hours, etc. Using the Diagnostics Logs setting, you can enable and disable the different kinds of diagnostics logging for your web app, as shown in Figure This includes any logging that the application may do, as well as IIS requests and Failed requests.
Scale Up will allow you to select a different pricing tier. This lets you increase the VM size, providing a different amount of memory, storage, etc. Figure shows the Scale Setting blade that you see when you click Scale Out.
Figure Scale Setting blade used for scaling out. Scaling out manually On the blade displayed in Figure , you can specify the number of instances that you want to run by either editing the text box with the number in it or dragging the slider over to the right. Figure 2- 33 shows an example requesting that the App Service plan should be scaled out to six instances. This means all apps running in app services that are assigned to that plan will now have six instances.
What if you have an application used by a small company, and usage is only high from 8 AM to 5 PM? Do you set it to handle the usage during the day and let it run at that size through the night? What if you just want to use a simple plan of increasing the instance size when your CPU percentage reaches a specific value, and decrease when the CPU percentage goes back down? Figure shows the options for Scale By in a drop-down list.
Figure Options for scaling out. You can see that you now have two more options. One is for scaling by CPU Percentage, and other option lets you put in specific rules for scaling. This will allow you to scale up or down depending on the CPU Percentage. You can set the lowest number of instances and the highest number of instances as well as the CPU Percentage value where you want the autoscaling to occur. In the case displayed in Figure , the web app will run on a minimum of two instances and a maximum of six instances.
The autoscaling uses standard Microsoft Insights autoscaling, creating an upper and lower bound rule that you can view using the Resource Explorer in the Microsoft. Insights resource for the App Service. It waits 10 minutes between each scaling action. In our case here, when the CPU Percentage reaches 80 percent and stays there for at least 10 minutes, it will start scaling up the instances until the CPU Percentage is below the limit or it reaches the maximum number of instances.
When the CPU Percentage is below the limit, it will scale down until it reaches the minimum number of instances. Note When talking about autoscaling, the average CPU percentage used to scale up or down is the average across all of the VMs running in that App Service plan.
This is also true for the other metrics you can use. You can also set up notifications so it will email you when it starts scaling up and configure a webhook to be run. Webhooks allow you to route the notification to other systems.
For example, you could have a service that sends you an SMS message when the scaling begins. You can set a schedule telling when to scale out and in, and you can even combine that with a performance metric. This is very useful when you want to be really specific about how your app scales out and in. You can do this by using this third setting, as shown in Figure Figure Custom scaling rules.
This comes with a default profile called Default, Scale Click Default, Scale to change the default profile as displayed in Figure This profile is called Test The Scaling Options, and it will apply all of the time. The minimum number of instances is two; the maximum number of instances is eight. Set the fields and click OK to add the profile.
Next, click Add Rule under the profile you just edited. This will bring up a blade similar to Figure Set this to autoscale based on CPU Percentage. In this case, when the average CPU Percentage is over 80 percent for more than 17 minutes, it will scale up by one instance. The Cool Down Minutes is the amount of time before another scaling action will take place. So after 5 minutes, if the average CPU Percentage is still over 80 percent, it will add another instance.
It will continue to do this until it reaches the maximum number of instances you set on the profile, which was eight. Fill in the fields and click OK to save the rule. It will keep decreasing the instance count until it reaches the minimum number of instances, which is two in our case. Figure shows how to set up this rule. Figure Set up a rule for scaling in. After filling in the fields, click OK to save the rule.
Now, the Scale Setting blade should look similar to Figure Click Save at the top of the Scale Setting blade to save the scaling settings. Now, the App Service plan will scale using these rules. Note that all Web Apps, Mobile Apps, etc. There are two other options for the profile—one is Recurrence and the other is Fixed Date. For example, you may want it to scale up faster on opening day for your web application. Recurrence allows you to specify a start time and which days of the week apply.
This is what you would use if you had a web application used by a company from 8 AM to 5 PM but not much after that. You would add a profile to start at 8 AM on Monday through Friday to scale out, and then add one to start at 5 PM on Monday through Friday to scale back in for the evenings and weekends.
If you have multiple profiles, there is an order of precedence in which they are handled. When processed by the Autoscale service, the profiles are always checked in the following order: 1. Fixed Date 2. Recurrence profile 3. Default Always profile In the example above, you would set up a Recurrence profile for Monday through Friday, 8 AM to 5 PM, and then set up a Fixed Date profile for a specific holiday, and the Fixed Date profile will take precedence on that one date.
However, not every solution can, or should, fit within the PaaS model. Some workloads require near-total control over the infrastructure: operating system configuration, disk persistence, the ability to install and configure traditional server software, and so on. What is Azure Virtual Machines? You have total control over the configuration of the VM.
You are responsible for all server software installation, configuration, and maintenance and for operating system patches. Note The terminology used to describe the Azure Virtual Machines feature and a virtual machine instance can be a little confusing.
Therefore, throughout this chapter, Azure Virtual Machines will refer to the feature, while virtual machine or VM will refer to an instance of an actual compute node. Azure Virtual Machines supports two types of durable or persistent disks: OS disks and data disks. An OS disk is required, and data disks are optional. The durability for the disks is provided by Azure Storage. By contrast, Azure PaaS cloud services use ephemeral disks attached to the physical host—the data on which can be lost in the event of failure of the physical host.
Because of the level of control afforded to the user and the use of durable disks, VMs are ideal for a wide range of server workloads that do not fit into a PaaS model.
If desired, users can move such workloads from an on-premises datacenter to one or more Azure regions, a process often called lift and shift.
Billing Azure Virtual Machines is priced on a per-hour basis, but it is billed on a per-minute basis. For example, you are only changed for 23 minutes of usage if the VM is deployed for 23 minutes.
The cost for a VM includes the charge for the Windows operating system. Linux-based instances are slightly cheaper because there is no operating system license charge. The cost, and the appropriate licensing, for any additional software you install is your responsibility.
You are charged separately for the durable storage the VM uses. When using the Azure CLI, there are two commands used to control the stopped state of a VM: azure vm stop and azure vm deallocate. That means that for the SLA to apply, there must be at least two instances of the VM deployed within an availability set.
Additional details pertaining to availability sets for Azure Virtual Machines are discussed later in this chapter. It is recommended that you use the Resource Manager model for new deployments.
The classic model is still supported; however, the newest innovations will be made available only for the Resource Manager model. For the purposes of this chapter, both models are covered, but the emphasis is on the Resource Manager model.
There are significant and fundamental differences in working with Azure Virtual Machines in these models. Azure Resource Manager model When working with the Resource Manager model, you have explicit and fine-grained control over nearly all aspects of the Azure VM. You will explicitly add components such as a network interface card NIC , public IP address, data disks, load balancer, and much more. You may recall that Resource Manager uses various resource providers to enable access to and management of Azure resources.
Network handles all aspects of network connectivity such as IP addresses, load balancers, NICs, and so on.
Compute handles details related to the VM itself, such as naming, operating system details, and configuration size, number of disks, and so on. The container provides several key features, including a DNS endpoint, network connectivity including from the public Internet if desired , security, and a unit of management. Use of the classic model also excludes the use of the additional value adding features available via Azure Resource Manager tags, template files, and so on.
Virtual machine components Like a car, there are many components that make up a virtual machine. Also like a car, there are multiple configuration options available to suit the specific functional needs and desires of the owner. The sections that follow describe several of the critical components of Azure Virtual Machines. Additionally, more advanced configuration options will be discussed later in the chapter.
But first, the base model needs to be established. Virtual machine It is sometimes helpful to think of an Azure VM as a logical construct. A virtual machine can be defined as having a status, a specific configuration operating system, CPU cores, memory, disks, IP address, and so on , and state. That logical definition can be instantiated by Azure, and the appropriate resources can be allocated to bring that VM to life. As a template, it does not have settings such as a machine name, administrative user, and so on.
More information on creating and using images is provided later in this chapter. There are two types of disks: an OS disk and a data disk. All durable disks the OS disk and data disks are backed by page blobs in Azure Storage. Therefore, the disks inherit the benefits of blob storage: high availability, durability, and geo-redundancy options. Blob storage provides a mechanism by which data can be stored safely for use by the VM. The disks can be mounted as drives on the VM. The Azure platform will hold an infinite lease on the page blob to prevent accidental deletion of the page blob containing the VHD, the related container, or the storage account.
Standard and Premium Storage The disk files. An OS disk is used precisely as the name suggests: for the operating system. The maximum size for an OS disk is currently 1, GB.
The other type of disk used in Azure Virtual Machines is a data disk. The data disk is also used precisely as the name would suggest: for storing a wide range of data.
The maximum size for a data disk is also 1, GB. The data disks are often used for storing application data, such as data belonging to your custom application, or server software, such as Microsoft SQL Server and the related data and log files. Multiple data disks can be made into a disk array using Storage Spaces on Windows or mdadm on Linux. Azure Virtual Machines also include a temporary disk on the physical host that is not persisted to Azure Storage.
The temporary disk is a physical disk located within the chassis of the server. Figure shows the various disk types. Figure Disk types in Azure Virtual Machines. Virtual Network In an on-premises physical infrastructure, you may have many components that all allow you to operate your virtual machines in a scalable and secure manner. These components could include equipment such as separate network spaces for Internet-facing and backend servers, load balancers, firewalls, and more.
However, you can use network security groups NSGs and user-defined routes to control such communication. A public IP address can be allocated dynamically— that is, created only when the associated resource such as a VM or load balancer is started and released when said resource is stopped—or statically, in which case the IP address is assigned immediately and persists until deleted. You will decide to use an existing VNET or create a new one , the subnet to use, the IP address, if there is a load balancer or not, the number of NICs, and how network security is handled, as depicted in Figure While it may seem like a lot just to get a VM deployed, these are important aspects to consider for the accessibility and security of the VM.
Figure VMs in the Resource Manager model have explicit control over related network components. However, this is not a requirement as it is with VMs in the Resource Manager model. Each NIC has an associated private address often referred to as a DIP, or dynamic IP used to connect to the virtual network and is optionally associated with a public IP address connected directly to the public Internet.
In the classic model, the story is similar except that NICs and public IP addresses can only exist in the context of a VM—that is, they are not independent resources. Furthermore, in the classic model, it is more usual to have Internet connectivity provided by the Azure Load Balancer rather than through a public IP Address. Azure Load Balancer As mentioned previously, the Azure Load Balancer is used to provide a relatively even distribution of network traffic across a set of often similarly configured or related VMs.
Using the load balancer allows you to have multiple VMs work together—for example, as a collection of web servers in a web farm environment. With a load-balanced set of VMs , incoming requests are distributed across the available VMs instead of being routed to a single VM. There are two types of load balancers available in Azure: an external load balancer and an internal load balancer, as depicted in Figure The external load balancer is used for distributing traffic from the Internet across one or more VMs.
This enables you to expose your application in a highly scalable and highly available manner. The internal load balancer is used to distribute traffic from within a virtual network across a set of VMs. For example, this could be traffic to a web API or database cluster that should be available only to front-end web servers, not to the public Internet.
All VMs in the cloud service are automatically configured to use the load balancer if they expose a public endpoint. Classic VMs can also use an internal load balancer.
When working with classic VMs, it is not necessary to worry about the NIC configuration because that is handled automatically as part of the cloud service model and cannot exist outside the context of a VM. Network security groups Network security groups NSGs allow you to have fine-grained and explicit control over how network traffic flows into or out of Azure VMs and subnets. NSGs allow you to shape the network traffic flow in and out of your environment.
You create rules based on the source IP address and port and the destination IP address and port. As with most physical devices, there is a chance that there could be a failure. If the physical server fails, the Azure VMs hosted on that server will also fail. Should a failure occur, the Azure platform will migrate the VM to a healthy host server on which to reconstitute the VM. This service-healing process could take several minutes.
During that time, the application s hosted on that VM will not be available. Besides hardware failures, the VMs could be affected by periodic updates initiated by the Azure platform itself.
During these updates, the VM will be rebooted and thus temporarily unavailable. To avoid a single point of failure, it is recommended to deploy at least two instances of the VM. This is a logical feature used to ensure that a group of related VMs are deployed so that they are not all subject to a single point of failure and not all upgraded at the same time during a host operating system upgrade in the datacenter.
The first two VMs deployed in an availability set are allocated to two different fault domains, ensuring that a single point of failure will not affect them both simultaneously. Similarly, the first five VMs deployed in an availability set are allocated to five different update domains, minimizing the impact when the Azure platform induces host operating system updates one update domain at a time.
VMs placed in an availability set should perform an identical set of functionalities. The number of fault domains and update domains is different depending on the deployment model— Resource Manager or classic. In the Resource Manager model, you can have up to 3 fault domains and 20 upgrade domains. With the classic model, you can have 2 fault domains and 5 upgrade domains. VMs in the Basic tier are well suited for workloads that do not require load balancing or the ability to autoscale. This tier is recommended for most production scenarios.
Starting with the F-Series and applying to any future VM sizes, a numeric value after the family name will match the number of CPU cores.
Additional capabilities, such as premium storage, will be designated by a letter following the CPU core count. This new naming standard will not be applied to previously introduced VM sizes. These are your general-purpose VMs. They carry the same memory and disk configuration as the D-Series, yet they are on average 35 percent faster than the D-Series thanks to the 2.
The F-Series can be an excellent choice for workloads that might not benefit from additional memory or local SSD space. At the time of this writing, N-Series VMs are limited to a private preview. One of the easiest ways to get started creating Azure VMs is to use the Azure portal. At this point, you will need an Azure subscription.
As can be seen in Figure , doing so opens the Virtual Machines Marketplace blade, where you can select from a wide range of VM configurations and preconfigured images from Microsoft, Microsoft partners, and ISVs. The images in the Marketplace include official images from Microsoft for Windows-based deployments such as Window Server , Microsoft SharePoint server farms, and more, and select partners such as Red Hat, Canonical, DataStax, Oracle, and many more.
Figure The Virtual Machines Marketplace. For the purposes of this example, select the Windows Server R2 Datacenter image. On the resulting blade, you can read information about the image, including any operating system updates. You will also have the option to choose a deployment model, either Resource Manager or Classic.
For the purposes of this example, choose Resource Manager. Click the Create button to proceed with creating your new VM. Note As Microsoft and its partners transition to the Resource Manager model, an increasing number of images in the Marketplace are only available via the Resource Manager model. Next, the Create Virtual Machine blade should open and then extend the first blade to configure basic settings. When finished with the Basics blade, click the OK button to proceed to the next step to select your VM size.
Not all VM sizes are available in all Azure regions. If a size is not available in the selected region, that size option will show as disabled when viewing all the VM sizes. This can be a new storage account or an existing storage account. This setting enables the Azure Diagnostics extension that by default persists metric data to an Azure Storage account.
This configuration cannot be changed once the VM is created. It is still necessary to enable the Azure Diagnostics extension — new configuration settings are used to optionally send the data to Azure Event Hubs.
The fourth, and final, step is a review step. Once some basic platform validation is complete, you will see a summary of the VM to be created. Select the OK button to start the deployment process. It may take several minutes before the VM is fully provisioned and ready for use.
Create a virtual machine with a template As mentioned in Chapter 1, one of the key features in the Resource Manager model is the ability to deploy full solutions, using many Azure services or resources , in a consistent and easily repeatable manner by using templates. Azure Resource Manager templates ARM templates are JSON-structured files that explicitly state each Azure resource to use, related configuration properties, and any necessary dependencies.
ARM templates are a great way to deploy solutions in Azure, especially solutions that include multiple resources. As a simple example, if you want to create a solution that requires two VMs using a public load balancer, you can do that in the Azure portal. In doing so, you will need to create a storage account or use an existing one , a virtual network, public IP addresses, an availability set, and a NIC for each VM.
If you have to do this in a repeatable or automated manner, using the Azure portal may not be an optimal approach due to risk of introducing human error into the process, speed of moving through a user interface, and so on. An alternative deployment mechanism would be to use an ARM template.
Connecting to a virtual machine After creating a new VM, one of the common next steps is to connect to the VM. Connectivity can be done by remotely accessing for example, logging in remotely to the VM for an interactive session or by configuring network access to allow other programs or services to communicate with the VM.
Figure Connecting to a VM. This will initiate a download to your local machine of a preconfigured Remote Desktop. You will need to provide the administrative user name and password set when initially provisioning the VM. If a Linux VM was created, the process to connect remotely will be a bit different because you will not connect via Remote Desktop.
To do so, a VM must be configured to permit inbound network traffic. Note Configuring network connectivity sets rules for how network traffic reaches the VM. It does not have any relation to the firewall software or similar features running on the VM itself.
NSGs can further restrain that connectivity. There are several blades to move through when viewing this information in the Azure portal. When using a load balancer in conjunction with one or more VMs in an availability set, the connectivity from the public Internet to the VM is controlled by inbound NAT rules and load balancing rules, as seen in Figure The rules are part of the load balancer resource configuration, not the VM.
The load balancer is configured to work with, or target, the specific VM s. This configuration is configuring the Azure Load Balancer to allow traffic from the Internet, creating a mapping between public ports on the Azure Load Balancer and private ports on the VM. For the purposes of this scenario on virtual machine connectivity, NSGs are not discussed for classic VMs.
Configuring and managing a virtual machine Creating an Azure VM is only the beginning. There are several important factors that you should consider to successfully manage the VMs. Factors such as scalability, SLA, disk management, and machine maintenance are all important to consider. There is a wide range of choices for configuring the VM—the choice is yours.
See Also Unfortunately, all VM configuration options and approaches cannot be covered in this book. These disks are durable or persistent disks backed by page blobs in Azure Storage. You have several options on for configuring and using the disks for your VM. Azure Storage uses page blobs to store the VHDs. Because of this, it is recommended that you use a quick format when formatting the disks.
A quick format will avoid storing large ranges of zeros with the page blob, thus conserving actual storage space and saving you money. However, if the VM uses Premium storage, you are charged for the full disk size. Meaning, if you attach a P20 disk which has a size of GB to a VM and allocate GB for the drive, you are charged the full price for the P20 disk not just the space used or allocated.
Caching potentially can reduce transactions to Azure Storage and can improve performance for certain workloads. You should thoroughly test the disk caching configuration for your workload to ensure it meets your performance objectives.
By browsing to the Disks options in the Settings menu, as seen in Figure , you can view all the OS and data disks that are attached to the current VM. This view also allows you to see the disk type Standard or Premium , size, estimated performance, and cache setting. Figure Number and size of disks. To create and attach a new disk, first click the Disks options in the Settings menu to open the Disks blade.
On this blade, you will be able to attach a new disk or attach an existing disk. You can either select an existing storage account and container or create a new storage account. Figure Attach a new data disk. To attach an existing data disk, click Attach Existing on the Disks blade. You can use your favorite Azure Storage management tool to upload an existing VHD to a blob container in the desired storage account be sure that VHD is set as a page blob and not a block blob. Formatting disks Once the data disks are attached to the Azure VM, each data disk needs to be formatted or initialized , just like a disk on a physical server.
Because Standard storage disks are billed only for the occupied space, it is recommended that you use a quick format when formatting the disks. To format the disk s , remotely connect to the VM. Disk Management is a native Windows application that allows you to view the disks and format any unallocated disks. As can be seen in Figure , proceed by right-clicking the unallocated disk and selecting Initialize Disk. Complete the wizard to initialize the disk.
Once the disk has been initialized, you can proceed with formatting the disk. Right-click the disk and select New Simple Volume. The New Simple Volume Wizard should open. Continue through the wizard, selecting the desired volume size and drive letter. When presented with an option to format the volume, be sure to select Perform A Quick Format.
Finish the steps in the wizard to start formatting the disk. This might or might not be sufficient for the desired workload. You should conduct performance tests to ensure the disk performance is sufficient.
If it is not, consider adding disks and creating a disk array via Storage Spaces on Windows or mdadm on Linux. Although the referenced whitepaper is specific to running SQL Server on an Azure VM, the disk configuration details are common across a multitude of workloads. Fault domains and update domains For Resource Manager VMs, you can view the update and fault domains by looking at the Availability Set resource associated with the VMs, as seen in Figure If there is an existing availability set, the VM can be placed within the availability set as part of the VM provisioning process.
If there is not an existing availability set, one will need to be created. The VM cannot be added to the availability set at a later time. You can view the update and fault domains used for your classic VMs by looking at the related Cloud Service Classic in the Azure portal. As seen in Figure , the first five VMs are each placed in a different update domain, and the sixth VM is placed in update domain 0. A similar view can be found in the Azure classic portal, as shown in Figure Image capture Once you have your new Azure VM configured as you would like it, you might want to create a clone of the VM.
For example, you might want to create several more VMs using the one you just created as a template. You do this by capturing the VM and creating a generalized VM image. When you create a VM image, you capture not only the OS disk, but also any attached data disks.
When you capture the VM to use it as a template for future VMs, you will no longer be able to use the original VM the original source because it is deleted after the capture is completed. As of this writing, there is no view available in the Azure portal for viewing images related to Resource Manager VMs. Capturing a VM is not yet possible in the Azure portal. To capture a Windows VM, complete the following steps: 1.
Connect to the VM using Remote Desktop as discussed earlier in this chapter. Open a command prompt window as the administrator. In the System Preparation Tool, perform the following actions: a. Select the Generalize check box. In the Shutdown Options drop-down list, select Shutdown.
The VM will run sysprep. Watch the VM in the Azure portal until it completely shuts down and shows a status of Stopped. This will show you a VM generalized status when the previous command is complete. The VM generalized status will not appear in the Azure portal. Statuses 9. Note that the value of the DestinationContainerName parameter is not a top-level blob container, but a folder under the System container, as can be seen in Figure You will need to add any additional required components, such as an NIC.
With the image safely stored in Azure Storage, you can use this image as the basis for new Azure VMs. Keep in mind that the image and the OS disk must be in the same storage account.
If they are not, you will need to copy the image VHD to the desired storage account. A full example can be seen below replace with your values as appropriate. This example assumes the new VM is in a different resource group and storage account from the captured VM. There, you will find options, as seen in Figure , to deallocate, generalize, and capture the VM. Capture a Windows VM in the classic model Similarly, in the classic model, there are several steps you will need to follow to capture a VM so it is available for use as a template image.
The majority of the steps are the same as in the Resource Manager model. Once the VM has executed the sysprep process or Linux equivalent , you will be able to initiate the capture process from within the Azure classic portal. Once the capture process is complete, the image will appear in your Virtual Machine gallery, under My Images. This means it is preferable to deploy more instances of the same configuration than to add larger, more powerful machines. Virtual Machine Scale Sets are a relatively new Azure compute option for deploying and managing a set of identical VMs.
You configure all VMs in a scale set in an identical manner. It is written with the developer who has experience using Visual Studio and the. NET Framework in mind. If Azure Web Apps is new to you, this book is for you. If you have experience developing for Azure Web Apps, this book is for you, too, because there are features and tools discussed in this text that are new to the platform.
The author, a content lead for Azure. Office Office Exchange Server.
0コメント