Azure 笔记

lonanx3

已于 2024-01-21 18:42:42 修改

阅读量414

点赞数 4

文章标签： azure 笔记 microsoft

于 2023-09-08 16:32:39 首次发布

本文链接：https://blog.csdn.net/lonanx3/article/details/132763005

版权

Azure 计算资源的选择

数据库选择

resource group和 subscription之间的关系

在构建azure时，需要考虑SLA 服务级别协议可用性，计算可用性多个SLA相乘

storage account 一种便宜的存储服务

Pricing Calculator | Microsoft Azure

计算资源的花费

设置预算预警

VM:

节省VM花费的方法：

auto shutdown, 适合 dev 和 uat环境，定时关闭服务器以节省花费

reserved instance，适合product 环境，需要预定很长时间以换取折扣

spot instance

Spot instances是一种实例类型，它允许你以更低的价格（有时甚至可以是负的“市场价格”）运行虚拟机（VM）。这是通过在Azure市场中拍卖未使用的计算能力来完成的。

当Azure中的实例需求高时，Spot instances的价格会上涨。如果市场价格变为正数，Azure会通知你，然后你有两种选择：

继续运行你的VM实例，但需要支付额外的费用。
关闭你的VM实例，并且不会产生任何额外费用。

磁盘优化

默认选择 premium SSD最贵的

如果的实例对于输入输出效率不敏感的话可以选择 standard SSD 比如应用服务器和内存缓存

磁盘类型可以影响SLA

选择合适的机器size

比如合适的cpu大小，以避免闲置

选择操作系统的类型

选择不同区域

VM 的可用性（availability）

Fault Domain

如果有多个主机，确保他们不在同一个机柜中（rack）否则因为电源和交换机故障导致所有的服务器都不可用

update domain

因为多个虚拟机存在与同一组自动更新主机中，当主机升级和重启时候，所有的虚拟机都不可用。分散服务器存在于多个不同主机中。

availability set

FD=Fault Domain

UD = update domain

fault domains & update domains are in the same zone

Availablity Zone

一个数据中心的不同楼栋，将不同的服务器放到不同的物理单元以提升可用性。

Azure ARM template 是一种显式声明的部署资源的方式

ARM代表Azure Resource Manager。ARM是一种基础设施即代码的方式，通过这种方式，可以定义需要部署的基础设施，减少创建资源时花在配置上的时间，并且可以通过代码进行自动化设置。

VM scale set

如果系统监测到负载满足特定条件就会扩展服务器的数量以满足临时的需求增长

如果scale set被设置了，就不应该再修改机器上的文件，安装软件。因为扩展的机器会以scale set设置时的镜像为基础扩展服务器，所以以上修改会被丢弃

对于web app 应用，需要在scale set 之前放一个load balancer

scale set免费，但需要为其中部署的vm付费

设计scale rules

10 分钟平均cpu使用率大于80%就增加一台服务器

并等待5分钟，再看是否符合条件

添加缩减条件

decrease by是减少多少

decrease to是减少到多少

设置好的rules

要启用scale set需要注册 microsoft.insights 在subscription中

Azure instance metadata services

A REST API provide info of machine, 只能在vm内部被访问到

可以获取资源会被驱逐的通知，如果你在监听元数据服务，会被通知去租（eviction）即将发生。

可以每一分钟拉取一次，以获得足够的时间来处理必要的关闭任务。

在VM中通过postman来调用metadata API：

http://169.254.169.254/metadata/instance?api-version=2021-12-13

这个IP地址是固定的，在任何vm中都是访问这个ip上的api

http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01

可以查询服务器上的定时任务使用上面的 API

mac 中发布.net应用，在程序根目录下执行

$ su mask
$ dotnet publish -o publish

执行后会生成publish文件夹

在vm中添加Web Server Roles

安装完毕后可以通过浏览器打开iis 默认站点页面。

安装 dotnet hosting bundle

新建一个catalog的站点

然后就可以通过localhost和对应的端口来访问新建的站点了

建立Weather服务器的ubuntu VM

lonanx@weather-vm:~$ sudo apt install git
Reading package lists... Done
Building dependency tree       
Reading state information... Done
git is already the newest version (1:2.25.1-1ubuntu3.11).
git set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
lonanx@weather-vm:~$ sudo apt update

安装git 更新update

lonanx@weather-vm:~$ sudo apt install nodejs
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following additional packages will be installed:
  libc-ares2 libnode64 nodejs-doc
Suggested packages:
  npm
The following NEW packages will be installed:
  libc-ares2 libnode64 nodejs nodejs-doc
0 upgraded, 4 newly installed, 0 to remove and 11 not upgraded.
Need to get 6806 kB of archives.
After this operation, 30.7 MB of additional disk space will be used.
Do you want to continue? [Y/n] Y

安装node js

lonanx@weather-vm:~$  sudo git clone https://github.com/memilavi/WeatherAPI.git
Cloning into 'WeatherAPI'...
remote: Enumerating objects: 406, done.
remote: Counting objects: 100% (406/406), done.
remote: Compressing objects: 100% (323/323), done.
remote: Total 406 (delta 74), reused 400 (delta 73), pack-reused 0
Receiving objects: 100% (406/406), 565.19 KiB | 7.06 MiB/s, done.
Resolving deltas: 100% (74/74), done.
lonanx@weather-vm:~$ cd WeatherAPI/
lonanx@weather-vm:~/WeatherAPI$ ls
index.js  node_modules  package-lock.json  package.json
lonanx@weather-vm:~/WeatherAPI$ sudo apt install npm

安装Weather API 从github

lonanx@weather-vm:~/WeatherAPI$ npm start

> todo-api@1.0.0 start /home/lonanx/WeatherAPI
> node index.js

Listening on port 8080

安装成功之后运行API

App services

可以运行代码，不用管理服务器，不用安装，不用补丁
不能访问和安装软件在底层的服务器中
安全合规由微软来负责，服务器总是保持在最新状态。
与许多devops流程集成在一起 GitHub bitbucket azure devops
支持多种语言 .net node.js java python php..
支持容器
支持的应用类型：web apps、web api、web jobs（batch process）
部署步骤：1.devlop your app 2.create web app 3. publish your code
app service 可以自动扩展

创建app service,可以选择免费的资源，但访问频率由限制

创建好之后可以通过vscode的，azure app service 插件来发布 pubulish的代码：

由于网络限制，所以我采取了 ftp部署的方式，在deployment center 中可以拿到ftp的地址和密码

通过FTP工具把发布后的publish目录内容全部上传到wwwroot目录中，再通过app service url 访问应用。

可以通过 App Service Editor来编辑app service上的代码

console可以运行命令在app service

在scale up/out 可以改变app service的类型，和支持自动扩展

VM如果关停就不会计费，但是app service不能被停止，所以会一直计费（除非你使用free plan），要停止app service计费就需要删除资源。

容器：

解决传统部署因为开发、部署环境不一致导致的潜在问题。

选择容器的原因：

1.可预测性，由于所需的包已经包含在容器中，可以保证各环境的一致性

2. 性能：容器可以几秒钟就启动，而vm通常要几分钟

3. 密度：一个服务器可以运行上千个容器，却只能运行几十个vm

不选择容器的原因：

1. 隔离性，容器比起VM来说，他们之间更容易互相影响，如果你的应用含有敏感数据，他们最好被放到隔离的VM中。

Docker的构建

中间是Docker server，一般安装的容器和它位于同一台机器上

Docker daemon是Docker架构中运行在后台的守护进程，是Docker最核心的后台进程，也被称为主进程。

images镜像包含了被运行的静态文件，但是他们不会被运行。他们从哪里来？

Docker Registry和Docker Hub之间是存储和分发镜像的关系。

Docker Hub是Docker提供的官方Docker Registry，也是默认的Registry

containers，就是images 运行的实体，容器在deamon创建的沙箱中运行

Client可以向 docker host中的deamon发送指令，通过它使用docker的功能，你可以建立容器，定义他们，关闭他们、检查状态等等。技术人员通常通过这个方式来管理docker

dockerfile：含有定制镜像指令的文件，指令包括拷贝文件，运行之类，更改工作目录等。通常他不会很大，因为有很多不同的基本镜像文件，需要自定义的内容并不太多。

docker被很多主流操作系统支持，云服务厂商也推出了自己的registry：如Azure ACR

Kubernetes为了解决容器的：

1. 路由管理

2. 扩展性

3.高可用性

4.自动部署

5.配置管理

。。。

pod可以看成是容器的容器，kubernetes中部署的最小单位，大多数情况下一个pod包含一个容器（允许含有多个），并含有一个公开的ip地址。这些ip地址可以用于建立于外部的通信，service隐藏了pod，只向外暴露pod中的服务。

一个dockerfile的示例：

FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 5004
ENV ASPNETCORE_URLS=http://+:5004

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["cart.csproj", "./"]
RUN dotnet restore "cart.csproj"
COPY . .
WORKDIR "/src/."
RUN dotnet build "cart.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "cart.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "cart.dll"]

通过container registeries 来添加一个容器注册表，plan可以选择basic，这样足够我们的实验价格合理。

为了避免连接 acr时候出现权限错误，需要做以下设置：

In the next video we're going to create and use Azure Container Registry.

Due to a recent change Microsoft implemented in ACR, you need to have specific permissions to access its repositories. If you don't have these permissions, you might encounter the following error when trying to access the repositories, which we'll do at ~11:45 mark of the video:

In order to avoid this error please follow these steps:

1. In the menu on the left click Access control (IAM)

2. Click + Add -> Add role assignment

3. Switch to the Privileged administrator roles tab

4. Select the Contributor role and click Next

5. Click + Select members and select your user from the list

6. Click Select, Review + assign, Review + assign again, and after assignment is complete go again to Repositories, and this time you won't see the error.

设置完成后通过vscode 就可以连接到你设置的acr啦

再通过dockerfile 右键，build image in Azure:

输入image 名称，选择ACR来创建镜像，成功后就可以在acr中看到你创建的image了

下面就可以开始创建aks了：

由于subscription 中的usage + quotas限制，我们对资源的创建受到制约，所以可以通过选择不同的区域来创建资源来绕过这个限制：

创建kubernetes的一些设置

下面的设置中mode 被改成了system：

在integrations里面选中之前创建的 container registry

创建AKS成功之后，可以通过下面的命令获取访问密码

az aks get-credentials --resource-group catlog-app-rg --name cart-aks

通过Azure Cloud Shell 可以上传deployment.yaml 文件到服务器

通过下面的代码部署image

evan-zz_ou [ ~ ]$ ls
clouddrive  deployment.yaml
evan-zz_ou [ ~ ]$ kubectl apply -f deployment.yaml
deployment.apps/readit-cart created
service/readit-cart created
evan-zz_ou [ ~ ]$

在aks中就可以看到已经发布成功的应用。

Azure functions:

serverless 不用管理和选择服务器配置，他只负责工作

在function中的两个重点，triggers 和 bindings

代码的运行有时候需要2-3秒的启动时间

如何避免cold start对azure function启动延迟的影响，选择 function hosting plan

选择一：consumption plan，有1.5G内存的限制

计算花费的例子

consumption的坏处：1.5G RAM限制、冷启动

2. premium plan

premium plan 没用内存的限制和冷启动

一个计算花费的例子

premium plan的坏处就是比较昂贵

3.dedicated （专用）plan

如果使用这个计划，请确保下面的开关被打开，否则app server有可能会关闭不在活动状态的function

dedicated plan的缺点是无法自动扩展

Durable functions:

有状态的功能，可以与外部资源交互并保持流程状态

非常简单呃语法结果，无需复杂的状态管理，retries 之类的操作。

举例：

链式功能-可以依此调用多个功能，把每个功能的输出应用到下一个调用

创建storage用于function：

evan-zz_ou [ ~ ]$ az storage account create --name readitevanstorage --location japanwest --resource-group catlog-app-rg --sku Standard_LRS

再创建function

evan-zz_ou [ ~ ]$ az functionapp create --name readitevanfunctionapp --storage-account readitevanstorage --consumption-plan-location japanwest --resource-group catlog-app-rg --functions-version 4

打开代码在workspace找到deploy

VNet（虚拟网络）:

同一个vNet下的资源可以互相访问

vNet免费

每个subscription中每个区域最多只能有50个VNet

每个VNet只存在于一个区域，所以不能跨区将不同区域的资源放到同一个vNet

vNet也只能存在单个 subscription中

vNet能通过Peering来连接，一个vNet的资源就可以与另外的vNet的资源连接啦

通过subnet将不同资源放入不同的子网中来方便管理，并与NSG结合

NSG是Network Security Group的缩写，是Azure中的一种网络安全组。它可以定义一系列的网络规则，以允许或阻止数据流量通过特定的端口、协议和源/目标组合。NSG是Azure中实现网络安全和隔离的一种重要工具。

使用vNet最重要的原因是security：

如何限制资源的访问来降低风险

每个VNet有自己的地址范围（也叫IP范围），默认情况下这有65，536个

所有的设备必须在这个地址范围以内

CIDR（classless inter-domain routing）是一种IP地址管理技术，用于将多个IP地址块组合成一个路由表项。它通过将具有相同前缀的地址组合在一起，简化了路由配置和管理。

下面的例子中/24, 表示这个ip地址中的前24位二进制：192.168.1是固定的，最后一个十进制位不固定，所以有8位2进制的地址范围。也就是192.168.1.0-192.168.1.255之间这个范围（一共256个地址，2的8次方）。

109.186.149.240/20

十进制149= 二进制：1001 0101

前20位分配给固定地址，所以149所代表的1001 0101（后四位被用来存储ip，也就是1001 0000 - 1001 1111-》144-159：所以对应的地址范围就是109.186.144.000 - 109.186.159.255 一共4096 个ip地址

Subnet 子网：

Vnet中的一个逻辑分类

subnet也会有ip范围，这个范围会占用vnet的ip范围

资源必须被放置再一共subnet中，不能直接放入vnet中

默认情况下，一个vnet中的不同subnet的资源可以互相通信，也可以被更改。

根据经验，最好不要在一个subnet中使用vnet中全部的地址范围，因为这个地址访问之后很难被修改。如果一个vnet中的ip范围被使用光了，就无法再添加新的subnet和资源了。

subnet免费，但一个vnet中最多使用3000个subnet

在创建vm的时候我们填入的vnet作为我们放入资源的环境，default是subnet

在vnet中，address space列出了地址空间。

创建vm的同时，会创建network interface，用来将vm与vnet连接起来。

subnet界面会列出地址范围和可用的ip地址数量。这里是10.0.0.0/24,整个vnet是10.0.0.0/16，所以还有空余的ip范围

创建Vnet时候可以选择IP地址范围，并添加subnet

NSG （network security group）

subnet守门员，定义谁可以连入，连出subnet

类似于一个mini防火墙

是subnet 创建的一部分

NSG是免费的

规则由5部分组成：

1. source （从哪里连接）

2. source port（从哪个端口连接）

3. destination （连接到哪里）

4. destination port （连接到哪个端口）

5 protocol 采取的是什么协议（TCP,UDP，Both）

基于以上5个数据，有允许和禁止两个状态，来构造安全规则 security rule

每个规则有一个number，number越小rule的优先级越高，需要防止优先级高的rule覆盖优先级低的rule

NSG会自动创建在VM的network interface创建时，默认会打开RDP在windows虚拟机上，或者SSH在Linux服务器上，由于我们不想让所有人都能连接服务器操作，所以创建vm之后我们需要设置NSG，这里我们可以看到现在vm拥有的nsg rules：

单击每一条rule，可以看到对应的细节

在上面你可以指定能够访问这个端口的来源地址

通常我们会将不同的应用放入不同的subnet，这样就可以单独定义他们的访问规则,在virtual network创建的时候会默认建立一个subnet.

创建subnet的时候可以附加一个NSG规则，也可以选择none。

如果需要将服务器放入新建的subnet中，需要点击资源对应的Network interface

再点击 IP configuration,就可以在右侧选择 subnet并提交修改。

放入到新的subnet后服务器的ip地址会发生变化

新建的NSG有默认的规则：

如果需要将他附加到一个 subnet上，点subnet 再点Associate 选择对应subnet

这个时候vnet内部的服务器之间还可以相互访问，但是外部到内部的访问会被阻止。例如从外部访问服务器的SSH（22）。

为了允许SSH的访问，我们需要建立一个允许的规则，点击 inbound security rules ，添加如下的rule，就可以通过service tag指定范围来源 AzureCloud,这样就能通过页面上的SSH来访问服务器了。

Network Security Groups Tips and Tricks

In addition to setting up security rule per IP (as we did in the demo), you can also set up rules that use Service Tags. These service tags represent well known sources which can be used in the rule, and you don't have to know their IP address.
Here is how it looks like:

Some common example for Service Tags are:
- Internet: All the requests coming from the internet
- VirtualNetwork: Requests coming from other Azure's Virtual Networks (this service tag is used by the default rule created for every NSG)
- LoadBalancer: Requests coming from Azure Load Balancer (this service tag is used by the default rule created for every NSG)
- AzureMonitor: Requests coming from Azure Monitor, and are used for monitoring the app
And lots more.
It's recommended to use Service Tags when your rule applies to built-in resources, and not resources created by you.

由于数据库等敏感资源需要被放置在单独的vnet中与其他网络隔离，

network peering 可以连接不同的vnet