Azure
1684914672
Introduction to Azure Arc-enabled Kubernetes
Introduction to Azure Arc-enabled Kubernetes
Learn how to work with Azure Arc-enabled servers, data services, and Kubernetes. In this session, learn how Azure Arc-enabled Kubernetes clusters can help customers like Contoso to optimize and simplify their operations. Describe Kubernetes, Azure Arc, and Azure Arc-enabled Kubernetes, connect Kubernetes clusters to Azure Arc, manage cluster configurations by using GitOps, and integrate clusters with Azure services such as Azure Monitor and Azure Policy.
#azure #kubernetes
1683960540
如何将 Azure Functions 从 JSDoc JavaScript 迁移到 TypeScript
在此 TypeScript - JavaScript 教程中，我们将了解如何将 Azure Functions 从 JSDoc JavaScript 迁移到 TypeScript。我使用 JSDoc JavaScript 实现了这个。我已经将它迁移到 TypeScript，我认为分享这个过程会很有趣。
为什么要从 JSDoc JavaScript 迁移到 TypeScript？
正如普通读者所知，我既是 TypeScript 的忠实粉丝，也是 JSDoc JavaScript 的忠实粉丝。我认为两者都很棒。那么为什么要从 JSDoc JavaScript 迁移到 TypeScript？对我来说，这主要是关于开发人员的经验；JSDoc 更冗长，而且更广泛的生态系统比 JSDoc JavaScript 做更多的 TypeScript。因此，当您超越简单的应用程序时，至少对我而言，TypeScript 是更好的选择。
我的博客是一个带有 Azure Functions 后端的Azure 静态 Web 应用程序。我一直在为我的 Azure Functions 使用 JSDoc JavaScript。这篇文章将采用后端并将其迁移到 TypeScript。我已经准备好了各种可供性，我不想在此过程中失去：
- 我可以在 VS Code 中调试
- 我使用 GitHub Actions 进行部署
- 我使用 Jest 进行了自动化测试
我可以通过 TypeScript 获得所有这些可供性，我想保留它们。让我们开始迁移。顺便说一句，此迁移的代码位于此 PR 中。
迁移tsconfig.json
我们tsconfig.json管理 TypeScript 编译器与我们的代码交互的方式。我们将从迁移开始：
``````diff title="tsconfig.json"
{
"compilerOptions": {
- “noEmit”：是的，
- “无发射”：假的，
- "outDir": "分布",
- "rootDir": ".",
“源地图”：真实的，
“allowJs”：假的，
“checkJs”：假的，
“moduleResolution”：“节点”，
}
}
让我们看看我们所做的更改：
- 由于设置noEmit为false. 我们将不再实际运行我们编写的代码，但我们将运行我们发出的 JavaScript。
- 我们指定了一个outDirof dist- 这是我们编译的 JavaScript 将被发出的地方。
- 我们指定了一个rootDirof .- 这是我们的 TypeScript 源文件的根目录。
- 我们正在为发出的 JavaScript 文件创建源映射——这将帮助我们调试原始源代码。（即使我们没有运行它。）
- allowJs由于设置为.js，我们不再允许 JavaScript 文件成为我们程序的一部分false。（而且我们也没有检查它们，因为被checkJs设置为false- 我怀疑这被隐式设置为-false只是为了清楚我已经指定了它。）allowJsfalse
- 我们正在指定一个moduleResolutionof node- 这是 TypeScript 将如何从给定的模块说明符中查找文件的方式。
迁移package.json
要迁移我们，package.json我们需要添加一些依赖项并调整我们的脚本：
```diff title="package.json"
"scripts": {
"build": "tsc",
- “观看”：“tsc -w”，
- "prestart": "npm run build", "start": "func start", "test": "jest" }, "devDependencies": { "@azure/functions": "^3.5.0",
- "@types/jest": "^29.2.5",
- "@types/node": "^18.x", "jest": "^29.3.1",
- “ts-jest”：“^29.1.0”，“打字稿”：“^5.0.0”}}```
我们添加了两个脚本：
- watch- 这将监视我们的 TypeScript 文件并在它们更改时重新编译它们 - 我们真的不需要这个；但它可能会很有用，具体取决于您喜欢的工作流程。
- prestart- 这将在之前运行start并确保我们的 TypeScript 文件被编译，并且我们有最新的 JavaScript 可以运行。
在我们的中，devDependencies我们添加了 Jest 和 Node.js 的依赖项。我们还添加了ts-jest这将允许我们运行用 TypeScript 编写的 Jest 测试。
迁移.vscode/settings.json和.vscode/tasks.json
我之前提到过调试——为了实现它，我们需要处理文件夹中的settings.json和tasks.json文件.vscode。首先settings.json：
```差异标题=“settings.json”
- "azureFunctions.projectLanguage": "JavaScript",
- “azureFunctions.projectLanguage”：“TypeScript”，```
以上是不言自明的。我们正在将 Azure Functions 项目的语言从 JavaScript 更改为 TypeScript。现在tasks.json：
```diff title="tasks.json"
{
"version": "2.0.0",
"tasks": [
- {
- “类型”：“外壳”，
- “标签”：“npm 构建（功能）”，
- “命令”：“npm 运行构建”，
- “dependsOn”：“npm 安装（功能）”，
- "problemMatcher": "$tsc",
- “选项”： {
- “cwd”：“${workspaceFolder}/blog-website/api”
- }
- }, ]}```
我们在这里有一个新任务来运行我们的npm run build脚本。这会将我们的 TypeScript 文件编译为 JavaScript。我们还有一个cwd设置blog-website/api- 这是我们的 Azure Functions 所在的文件夹 - 你自己的可能会有所不同。除了这个新脚本，还有对现有任务的一些调整，使它们依赖于我们的新构建任务：
```diff title="tasks.json"
{
"version": "2.0.0",
"tasks": [
{
"type": "func",
"label": "func: host start",
"command" : "host start",
"problemMatcher": "$func-node-watch",
"isBackground": true,
- “dependsOn”：“npm 构建（函数）”，
- “选项”： {
- “cwd”：“${workspaceFolder}/blog-website/api”
- } }, // ... { "type": "shell", "label": "npm prune (functions)", "command": "npm prune --production",
- "dependsOn": "npm build (functions)", "problemMatcher": [], "options": { "cwd": "${workspaceFolder}/blog-website/api" } } ] } ```
迁移我们的 Azure Functions
这不是从 JSDoc JavaScript 迁移到 TypeScript 的详尽指南。我将重点关注我发现与 Azure Functions 最相关的内容。fallback/function.json让我们从为我们的动态重定向提供支持并位于以下位置的文件开始/api/fallback：
```diff title="fallback/function.json"
{
"bindings": [
{
"authLevel": "anonymous",
"type": "httpTrigger",
"direction": "in",
"name": "req ",
"methods": ["get", "post"]
},
{
"type": "http",
"direction": "out",
"name": "res"
}
],
- “脚本文件”：“../dist/fallback/index.js”}```
这里有一个添加项，用于将 重新scriptFile指向已编译的 JavaScript。
现在让我们看一下该函数的代码。index.js最初是一个名为;的 JavaScript 文件。它必须重命名为index.ts. 原始代码如下所示：
```js title="fallback/index.js"
const redirect = require('./redirect');
const saveToDatabase = require('./saveToDatabase');
/**
*
- @param { import("@azure/functions").Context } 上下文
- @param { import("@azure/functions").HttpRequest } req */ async function fallback(context, req) { //... }
module.exports = 回退；
After renaming to `index.ts` and adding some TypeScript types, it looks like this:
```ts title="fallback/index.ts"
import type { AzureFunction, Context, HttpRequest } from '@azure/functions';
import { redirect } from './redirect';
import { saveToDatabase } from './saveToDatabase';
const httpTrigger: AzureFunction = async function (
context: Context,
req: HttpRequest
): Promise<void> {
//...
};
export default httpTrigger;正如我们所见，导入的类型变得更加简洁。我们还将函数导出为而default不是module.exports. 这是因为我们使用 ES 模块而不是 CommonJS 模块进行创作。我们还可以看到我们正在使用import而不是require导入我们的函数。虽然 CommonJS 使用起来更直接，但 ES 模块的语法使用起来感觉更好；至少对我来说。（值得注意的是，我们没有在编译的 JavaScript 中使用 ES 模块——我们仍然在那里使用 CommonJS；但我们在编写代码时不需要考虑这一点。）
我不会逐步迁移其他文件，但过程是相同的。将文件重命名为.ts，添加 TypeScript 类型，并使用import而不是require.
迁移我们的测试
我们现在几乎已经到了最后阶段；我们只需要迁移我们的测试。让我们从jest.config.js：
```diff title="jest.config.js"
- 预设：'ts-is'，
- testPathIgnorePatterns: ['/node_modules/', '/dist/'], ```
我们正在添加一个preset，ts-jest这将允许我们运行 TypeScript 测试。如果您还记得我们ts-jest之前添加的依赖项；就是为了这个。
我们还添加dist了testPathIgnorePatterns- 这是因为我们不想针对编译的 JavaScript 运行我们的测试 - 如果没有这个，我们最终会运行两次测试。
让我们直接将注意力转移到测试上。我们再次进行经典的重命名 from .jsto .ts，我们的导入变得更简洁，更符合 ES 模块：
```diff title="redirect.test.ts"
-/**
- * @typedef { import("@azure/functions").Logger } 记录器
- */ +import type { Logger } from '@azure/functions'; -const { describe, expect, test } = require('@jest/globals'); +import { describe, expect, test } from '@jest/globals'; -const redirect = require('./redirect'); +从'./redirect'导入{重定向}；```
美丽的。最后，我们对测试本身的代码进行了一些调整。首先，声明我们的模拟变得容易得多：
```diff title="redirect.test.ts"
-/** @type {jest.Mock} */ const mockLogger = jest.fn();
+const mockLogger: jest.Mock = jest.fn();
Secondly, casting our mock to the type we want is much more straightforward:
```diff title="redirect.test.ts"
-/** @type {any} */ (mockLogger)
+mockLogger as unknown as Logger我不知道如何as在 JSDoc 中进行两次转换 - 现在我不需要了。
结论
我们现在拥有一个 TypeScript Azure Functions 代码库，其中包含我们之前拥有的所有调试/测试/部署功能。我们不需要围绕部署做任何事情，因为它可以正常工作™️。我希望这篇文章对你有用！
文章来源： https: //dev.to
1683938520
选择 Azure 存储服务
在本 Azure 教程中，我们将了解如何选择合适的 Azure 存储服务？。Azure Storage 是 Microsoft 基于云的存储解决方案。它超越了传统的文件存储，提供了全面的现代存储服务。本文将探讨可用的各种服务及其特定用例，使您能够选择最适合您需求的服务。
Azure Blob 存储：轻松存储非结构化数据
Azure Blob 存储是一种功能强大且可扩展的存储服务，专为存储非结构化数据而设计。无论是图像、视频、文档、备份、日志还是任何其他类型的文件，Blob Storage 都为管理云中的海量数据提供了一种经济高效且可靠的解决方案。
Azure Blob 存储的用例
- 媒体和内容交付：为内容交付网络 (CDN) 和媒体流平台高效存储和提供图像、视频和音频文件。
- 备份和灾难恢复：安全地存储和访问备份，确保数据保护并实现轻松的灾难恢复。
- 数据存档：通过经济高效地存档数据以实现长期保留和历史目的，从而遵守法规要求。
- 日志和物联网数据存储：处理日志数据和物联网遥测的高吞吐量摄取和存储，以进行实时分析和历史分析。
- 分布式应用程序存储：作为跨分布式应用程序共享数据的中央存储库，促进高效的数据交换和协作。
- 数据迁移和导入/导出：使用导入/导出服务简化数据迁移到云端并通过物理运输传输大量数据。
Azure 文件：云中的高性能文件共享
Azure 文件用于在 VM 之间设置共享文件系统。网络文件共享允许您集中文件存储，提供多个用户或系统可以访问和协作处理文件的单一位置。这简化了文件管理并消除了对单个文件副本或分散存储位置的需要。
Azure Blob 存储和 Azure 文件之间的区别
Blob 存储旨在存储非结构化数据，例如图像和视频，并通过 REST API 进行访问。另一方面，Azure Files提供文件级存储，支持SMB和NFS协议共享访问结构化数据，适合传统文件系统场景，易于与现有应用集成。
Azure 表：用于可扩展应用程序的 NoSQL 键值存储
Azure Tables 是一种 NoSQL 键值存储服务。它旨在以高度可扩展和高效的方式处理大量结构化数据。它提供了灵活的模式、快速的访问时间和自动扩展，使其成为构建需要快速和可扩展数据存储的应用程序的理想选择。有关 Azure 表存储入门的更多信息，请阅读 Azure 表存储入门
用例
- Web 应用程序和用户数据存储。
- IoT 数据摄取和分析。
- 日志记录和审计跟踪管理。
- 内容管理系统 (CMS) 和结构化内容存储。
- 元数据存储和索引。
Azure 队列：可扩展应用程序的可靠消息传递
Azure 队列是一种消息传递服务，可在分布式应用程序的组件之间提供异步和可靠的通信。它为解耦服务提供了一个简单且可扩展的解决方案，确保可靠的消息传递并实现工作负载的高效处理。它不支持主题，您必须使用 Azure 服务总线。
以下是队列可以帮助您的一些用例：
- 用于异步处理的任务卸载和工作队列。
- 事件驱动的架构和通知。
- 分布式应用程序中可靠的组件间通信。
- 紧急或重要任务优先处理。
- 缓冲和负载均衡以处理工作负载高峰。
- 工作流编排和协调。
文章来源： https: //www.c-sharpcorner.com
1683936600
Как перенести функции Azure из JSDoc JavaScript в TypeScript
В этом учебном пособии по TypeScript — JavaScript мы узнаем, как перенести функции Azure из JSDoc JavaScript в TypeScript. Я реализовал это с помощью JSDoc JavaScript. С тех пор я перенес это на TypeScript и подумал, что было бы интересно поделиться процессом.
Зачем переходить с JSDoc JavaScript на TypeScript?
Как известно постоянным читателям, я большой поклонник TypeScript и большого поклонника JSDoc JavaScript. Я думаю, что оба великолепны. Так зачем переходить с JSDoc JavaScript на TypeScript? Для меня это в основном опыт разработчика; JSDoc более многословен, а более широкая экосистема использует гораздо больше TypeScript, чем JSDoc JavaScript. Поэтому, когда вы выходите за рамки простого приложения, по крайней мере для меня, TypeScript — лучший выбор.
Мой блог — это статическое веб-приложение Azure с серверной частью функций Azure. Я использую JSDoc JavaScript для своих функций Azure. Этот пост возьмет серверную часть и перенесет ее на TypeScript. У меня уже есть различные возможности, которые я не хочу терять по пути:
- Я могу отлаживать в VS Code
- Я развертываю с помощью GitHub Actions
- У меня есть автоматизированные тесты с использованием Jest
Все эти возможности доступны мне с TypeScript, и я хочу их сохранить. Начнем миграцию. Кстати, код этой миграции лежит в этом PR .
Миграцияtsconfig.json
Наш tsconfig.jsonуправляет тем, как компилятор TypeScript взаимодействует с нашим кодом. Мы начнем с переноса этого:
``````diff title="tsconfig.json"
{
"compilerOptions": {
- "noEmit": правда,
- "noEmit": ложь,
- "outDir": "расстояние",
- "rootDir": ".",
"исходная карта": правда,
"разрешить": ложь,
"checkJs": ложь,
"moduleResolution": "узел",
}
}
Давайте посмотрим на изменения, которые мы сделали:
- Теперь мы испускаем файлы из нашей компиляции благодаря тому, что для нас noEmitустановлено значение false. Мы больше не будем запускать написанный нами код, но будем запускать создаваемый нами JavaScript.
- Мы указываем outDirиз dist— здесь будет сгенерирован наш скомпилированный JavaScript.
- Мы указываем rootDirиз .— это корень наших исходных файлов TypeScript.
- Мы создаем исходные карты для наших созданных файлов JavaScript — это поможет нам отлаживать исходный код. (Хотя мы его и не запускаем.)
- Мы больше не позволяем файлам JavaScript быть частью нашей программы из-за того, что для них allowJsзадано значение false. (И мы также не проверяем их благодаря тому, что checkJsони установлены на false— я подозреваю, что это неявно установлено на — falseпросто для ясности, я указал это.)allowJsfalse
- Мы указываем moduleResolutionиз node— именно так TypeScript будет искать файл из данного спецификатора модуля.
Миграцияpackage.json
Чтобы перенести наш, package.jsonнам нужно добавить некоторые зависимости и настроить наши скрипты:
``diff title="package.json"
"скрипты": {
"сборка": "tsc",
- "смотреть": "tsc -w",
- "prestart": "npm run build", "start": "func start", "test": "jest" }, "devDependencies": { "@azure/functions": "^3.5.0",
- "@types/jest": "^29.2.5",
- "@types/node": "^18.x", "шутка": "^29.3.1",
- "ts-jest": "^29.1.0", "машинопись": "^5.0.0" } } ```
Добавляем два скрипта:
- watch- это будет следить за нашими файлами TypeScript и перекомпилировать их, когда они изменятся - нам это на самом деле не нужно; но это может быть полезно в зависимости от вашего предпочтительного рабочего процесса.
- prestart- это будет запущено раньше startи обеспечит компиляцию наших файлов TypeScript, и у нас будет обновленный JavaScript для запуска.
В нашем devDependenciesмы добавляем зависимости для Jest и Node.js. Мы также добавляем ts-jest, что позволит нам запускать тесты Jest, написанные на TypeScript.
Миграция .vscode/settings.jsonи.vscode/tasks.json
Я упоминал об отладке ранее — чтобы получить ее, нам нужно поработать с файлами settings.jsonи tasks.jsonв .vscodeпапке. Сначала settings.json:
``diff title="settings.json"
- "azureFunctions.projectLanguage": "JavaScript",
- "azureFunctions.projectLanguage": "TypeScript", ```
Вышеизложенное довольно понятно. Мы меняем язык нашего проекта функций Azure с JavaScript на TypeScript. Теперь tasks.json:
``diff title="tasks.json"
{
"версия": "2.0.0",
"задачи": [
- {
- "тип": "оболочка",
- "label": "сборка npm (функции)",
- "команда": "npm запустить сборку",
- "dependsOn": "установить npm (функции)",
- "проблемматчер": "$tsc",
- "параметры": {
- "cwd": "${workspaceFolder}/блог-веб-сайт/api"
- }
- }, ] } ```
У нас есть новая задача, которая запускает наш npm run buildскрипт. Это скомпилирует наши файлы TypeScript в JavaScript. У нас также есть cwdнабор blog-website/api— это папка, в которой живут наши функции Azure — ваша собственная, скорее всего, будет другой. Наряду с этим новым скриптом есть некоторые изменения в существующих задачах, чтобы они зависели от нашей новой задачи сборки:
```diff title="tasks.json"
{
"версия": "2.0.0",
"задачи": [
{
"type": "func",
"label": "func: host start",
"command" : "host start",
"problemMatcher": "$func-node-watch",
"isBackground": правда,
- "dependsOn": "сборка npm (функции)",
- "параметры": {
- "cwd": "${workspaceFolder}/блог-веб-сайт/api"
- } }, // ... { "type": "shell", "label": "npm prune (функции)", "command": "npm prune --production",
- "dependsOn": "npm build (функции)", "problemMatcher": [], "options": { "cwd": "${workspaceFolder}/blog-website/api" } } ] } ```
Перенесите наши функции Azure
Это не исчерпывающее руководство по переходу с JSDoc JavaScript на TypeScript. Я собираюсь сосредоточиться на вещах, которые я считаю наиболее важными для функций Azure. Давайте начнем с fallback/function.jsonфайла, который поддерживает наши динамические перенаправления и находится по адресу /api/fallback:
```diff title="fallback/function.json"
{
"bindings": [
{
"authLevel": "anonymous",
"type": "httpTrigger",
"direction": "in",
"name": "req ",
"methods": ["get", "post"]
},
{
"type": "http",
"direction": "out",
"name": "res"
}
],
- "scriptFile": "../dist/fallback/index.js" } ```
Здесь есть одно дополнение, чтобы указать на scriptFileскомпилированный JavaScript.
Теперь давайте посмотрим на код функции. Первоначально файл JavaScript с именем index.js; его нужно переименовать в index.ts. Исходный код выглядел так:
```js title="fallback/index.js"
const redirect = require('./redirect');
const saveToDatabase = require('./saveToDatabase');
/**
*
- @param { import("@azure/functions").Context } контекст
- @param { import("@azure/functions").HttpRequest } req */ резервная функция асинхронной функции (context, req) { //... }
module.exports = запасной вариант;
After renaming to `index.ts` and adding some TypeScript types, it looks like this:
```ts title="fallback/index.ts"
import type { AzureFunction, Context, HttpRequest } from '@azure/functions';
import { redirect } from './redirect';
import { saveToDatabase } from './saveToDatabase';
const httpTrigger: AzureFunction = async function (
context: Context,
req: HttpRequest
): Promise<void> {
//...
};
export default httpTrigger;Как мы видим, импорт типа стал намного лаконичнее. Мы также экспортируем функцию как, defaultа не module.exports. Это связано с тем, что мы используем для разработки модули ES, а не модули CommonJS. Мы также можем видеть, что мы используем import, а не requireимпортируем наши функции. В то время как CommonJS был более простым в использовании, синтаксис модулей ES кажется гораздо более удобным; по крайней мере мне. (Стоит отметить, что мы не используем ES-модули в нашем скомпилированном JavaScript — мы все еще используем там CommonJS, но нам не нужно думать об этом, когда мы пишем наш код.)
Я не буду рассказывать о переносе других файлов, но процесс такой же. Переименуйте файл в .ts, добавьте типы TypeScript и используйте importвместо require.
Миграция наших тестов
Сейчас мы почти на финишной прямой; нам просто нужно перенести наши тесты. Начнем с jest.config.js:
``diff title="jest.config.js"
- предустановка: 'ts-is',
- testPathIgnorePatterns: ['/node_modules/', '/dist/'], ```
Мы добавляем один presetиз ts-jestних, который позволит нам запускать тесты TypeScript. Если вы помните, мы добавили ts-jestзависимость ранее; это было для этого.
Мы также добавляем distк нашему testPathIgnorePatterns— это потому, что мы не хотим запускать наши тесты против нашего скомпилированного JavaScript — без этого мы бы запустили тесты дважды.
Обратимся непосредственно к тестам. Снова мы делаем классическое переименование from .jsв .ts, и наш импорт становится более кратким и более ES Module-y:
``diff title="redirect.test.ts"
-/**
- * @typedef { import("@azure/functions").Logger } Регистратор
- */ +import type { Logger } from '@azure/functions'; -const {описать, ожидать, тестировать} = требовать('@jest/globals'); +импорт {описать, ожидать, тестировать} из '@jest/globals'; -const перенаправление = требуется('./перенаправление'); +импорт { перенаправления } из './redirect'; ```
Красивый. Наконец, у нас есть некоторые изменения в коде самих тестов. Во-первых, объявление нашего макета становится намного проще:
```diff title="redirect.test.ts"
-/** @type {jest.Mock} */ const mockLogger = jest.fn();
+const mockLogger: jest.Mock = jest.fn();
Secondly, casting our mock to the type we want is much more straightforward:
```diff title="redirect.test.ts"
-/** @type {any} */ (mockLogger)
+mockLogger as unknown as LoggerУ меня нет реального способа asдважды приводить в JSDoc - и теперь мне это не нужно.
Заключение
Теперь у нас есть кодовая база TypeScript Azure Functions со всеми возможностями отладки, тестирования и развертывания, которые у нас были раньше. Нам не нужно было ничего делать с развертыванием, потому что это просто работает™️. Надеюсь, этот пост был вам полезен!
Источник статьи: https://dev.to
1683914520
Выберите службу хранилища Azure
В этом руководстве по Azure мы узнаем, как правильно выбрать службу хранилища Azure? Azure Storage — это облачное хранилище Microsoft. Это выходит за рамки традиционного хранилища файлов, предлагая широкий спектр современных услуг хранения. В этой статье будут рассмотрены различные доступные службы и их конкретные варианты использования, что позволит вам выбрать службу, которая наилучшим образом соответствует вашим потребностям.
Хранилище BLOB-объектов Azure: удобное хранение неструктурированных данных
Хранилище BLOB-объектов Azure — это мощная и масштабируемая служба хранения, разработанная специально для хранения неструктурированных данных. Будь то изображения, видео, документы, резервные копии, журналы или файлы любого другого типа, хранилище BLOB-объектов предоставляет экономичное и надежное решение для управления огромными объемами данных в облаке.
Варианты использования хранилища BLOB-объектов Azure
- Доставка мультимедиа и контента: эффективно храните и обслуживайте изображения, видео и аудиофайлы для сетей доставки контента (CDN) и платформ потоковой передачи мультимедиа.
- Резервное копирование и аварийное восстановление. Безопасное хранение резервных копий и доступ к ним, гарантирующие защиту данных и простое аварийное восстановление.
- Архивирование данных: Соблюдайте нормативные требования за счет экономичного архивирования данных для долгосрочного хранения и исторических целей.
- Хранение журналов и данных Интернета вещей: управление высокопроизводительным приемом и хранением данных журналов и телеметрии Интернета вещей для аналитики в реальном времени и исторического анализа.
- Распределенное хранилище приложений: служит центральным хранилищем данных, совместно используемых распределенными приложениями, способствуя эффективному обмену данными и совместной работе.
- Миграция данных и импорт/экспорт. Упростите миграцию данных в облако и переносите большие объемы данных посредством физической доставки с помощью службы импорта/экспорта.
Файлы Azure: высокопроизводительный общий доступ к файлам в облаке
Файлы Azure используются для настройки общей файловой системы между виртуальными машинами. Сетевой общий доступ к файлам позволяет централизовать хранилище файлов, предоставляя единое место, где несколько пользователей или систем могут получать доступ к файлам и совместно работать над ними. Это упрощает управление файлами и устраняет необходимость в отдельных копиях файлов или разбросанных местах хранения.
Разница между хранилищем BLOB-объектов Azure и файлами Azure
Хранилище BLOB-объектов предназначено для хранения неструктурированных данных, таких как изображения и видео, и доступ к ним осуществляется через REST API. С другой стороны, Azure Files предоставляет хранилище на уровне файлов, поддерживая протоколы SMB и NFS для общего доступа к структурированным данным, что делает его подходящим для традиционных сценариев файловой системы и простой интеграцией с существующими приложениями.
Таблицы Azure: хранилище ключей и значений NoSQL для масштабируемых приложений
Azure Tables — это служба хранения ключей и значений NoSQL. Он предназначен для обработки больших объемов структурированных данных с высокой масштабируемостью и эффективностью. Он обеспечивает гибкую схему, быстрое время доступа и автоматическое масштабирование, что делает его идеальным для создания приложений, которым требуется быстрое и масштабируемое хранилище данных. Дополнительные сведения о начале работы с хранилищем таблиц Azure см. в статье Начало работы с хранилищем таблиц Azure.
Случаи использования
- Веб-приложения и хранилище пользовательских данных.
- Прием и аналитика данных IoT.
- Ведение журналов и аудита.
- Системы управления контентом (CMS) и хранение структурированного контента.
- Хранение и индексация метаданных.
Очереди Azure: надежный обмен сообщениями для масштабируемых приложений
Очереди Azure — это служба обмена сообщениями, обеспечивающая асинхронную и надежную связь между компонентами распределенных приложений. Он предоставляет простое и масштабируемое решение для разделения сервисов, обеспечивая надежную доставку сообщений и эффективную обработку рабочих нагрузок. Он не поддерживает темы, вам нужно использовать служебную шину Azure.
Ниже приведены некоторые примеры использования очередей, в которых вам помогут:
- Разгрузка задач и рабочие очереди для асинхронной обработки.
- Архитектуры и уведомления, управляемые событиями.
- Надежная межкомпонентная связь в распределенных приложениях.
- Приоритетная обработка срочных или важных задач.
- Буферизация и выравнивание нагрузки для обработки скачков рабочей нагрузки.
- Организация и координация рабочего процесса.
Источник статьи: https://www.c-sharpcorner.com
1683894240
Azure 安全控制 - 身份和访问控制
在本 Azure 教程中，我们将了解 Azure 安全控制 - 身份和访问控制。
Azure 安全控制
Azure 是 Microsoft 的一项云计算服务，它提供了广泛的工具和服务来构建、部署和管理云中的应用程序和服务。与任何云服务一样，安全是用户最关心的问题。在本文中，我们将讨论 Azure 提供的安全控制，以确保用户数据的机密性、完整性和可用性。
访问管理
访问管理是 Azure 中的基本安全控制之一。Azure Active Directory (AD) 是身份和访问管理服务，可提供对 Azure 中资源的安全访问。它允许管理员管理用户身份、访问权限和多重身份验证设置。
Azure AD 还支持与外部身份提供者集成，例如 Active Directory 联合身份验证服务 (ADFS)，使用户能够使用其本地凭据进行身份验证。
网络安全
Azure 提供多种网络安全控制来保护云中的资源和数据。Azure 防火墙是一种网络安全服务，可为传入和传出流量提供状态防火墙功能。它允许管理员根据应用程序、端口和协议创建和实施网络安全策略。
Azure 虚拟网络 (VNet) 是一个专用网络，使用户能够在云中创建隔离的网络环境。它支持各种网络安全功能，包括允许管理员根据源和目标 IP 地址、端口和协议过滤网络流量的网络安全组 (NSG)。
数据保护
Azure 提供了广泛的数据保护功能来保护存储在云中的数据。Azure 存储提供不同类型的数据存储选项，包括 Blob、文件和队列存储，以及各种数据保护机制，例如静态和传输中的加密。
Azure Key Vault 是一种基于云的服务，允许用户安全地存储和管理应用程序和服务中使用的加密密钥、证书和机密。它提供具有访问控制策略和审计日志的集中式密钥管理解决方案。
合规与治理
Azure 提供合规性和治理功能来帮助用户满足法规和合规性要求。Azure Policy 是一种服务，使管理员能够为部署在 Azure 中的资源创建和实施策略。它允许用户确保根据组织标准和法规要求配置资源。
Azure 安全中心是一种统一的安全管理解决方案，可提供对整个 Azure 环境的安全性的可见性和控制。它提供持续的安全评估、威胁检测和补救建议。
总之，Azure 提供了强大的安全控制来确保用户数据的机密性、完整性和可用性。本文中讨论的安全控制只是 Azure 提供的众多功能中的一小部分。用户必须理解这些控制并适当地实施它们以保护他们在云中的资源和数据。
加密
加密是保护静态和传输中数据的关键安全控制。Azure 提供各种加密选项来保护数据，例如 Azure 磁盘加密和 Azure 存储服务加密。Azure 磁盘加密通过加密操作系统和数据磁盘来帮助保护 Azure 虚拟机上的数据。Azure 存储服务加密对存储在 Azure 存储帐户中的静态数据进行加密。
此外，Azure Key Vault 还支持硬件安全模块 (HSM)，以提供更安全和防篡改的密钥存储和加密操作。
威胁防护
Azure 安全中心是 Azure 中的一个关键安全管理解决方案，有助于防范威胁和漏洞。它提供了整个 Azure 环境的统一安全视图，可以帮助实时识别和缓解安全威胁。
Azure 安全中心与 Azure Log Analytics 集成，后者收集和分析来自各种 Azure 服务和资源的日志数据。Azure 安全中心使用此数据提供威胁情报、检测异常并在检测到可疑活动时生成警报。
监控和审计
Azure 提供监视和审计功能，以帮助用户跟踪和审查其环境中的活动。Azure Monitor 是一种从各种 Azure 资源和服务收集和分析遥测数据的服务。它提供了一个集中位置，用于监视和警告整个环境中的事件和指标。
Azure 审核日志提供有关对 Azure 中的资源所做更改的详细信息。此信息包括谁进行了更改、更改了什么以及更改发生的时间。Azure 审核日志可以通过提供环境中活动的可审核记录来帮助满足合规性和法规要求。
灾难恢复
灾难恢复是业务连续性规划的一个重要方面。Azure 提供了多种灾难恢复选项，例如 Azure Site Recovery 是虚拟机的灾难恢复解决方案，Azure Backup 为存储在 Azure 中的数据提供备份和还原功能。
Azure 还提供异地冗余存储，可将数据复制到次要区域以提供高可用性和灾难恢复功能。用户可以从不同的复制选项中进行选择，例如 LRS（本地冗余存储）、ZRS（区域冗余存储）和 GRS（地理冗余存储）。
总之，Azure 提供了一套全面的安全控制，有助于确保用户数据的机密性、完整性和可用性。适当地实施这些控制可以帮助用户保护他们在云中的资源和数据。
身份和访问管理
Azure 提供了一个强大的身份和访问管理 (IAM) 系统，可以对 Azure 资源的访问进行精细控制。借助 Azure IAM，管理员可以根据用户的角色和职责授予对资源的访问权限，从而降低未经授权访问的风险。
Azure 还支持多因素身份验证 (MFA) 以提高安全性。这要求用户在访问资源之前提供额外的身份证明，例如电话或短信。
遵守
Azure 提供合规性认证和审计报告，证明 Azure 符合各种行业法规和标准，例如 ISO 27001、HIPAA 和 PCI DSS。这些认证和报告提供了 Azure 满足严格的安全性和合规性标准的独立保证。
Azure 还提供合规性工具，例如 Azure Policy 帮助用户创建和实施合规性策略，以及 Azure 安全中心提供持续监控和合规性评估。
应用安全
Azure 提供了多种安全控制来帮助保护部署在 Azure 中的应用程序。Azure 应用程序网关是一种 Web 流量负载均衡器，可提供第 7 层负载均衡和应用程序交付功能，例如 SSL 卸载、基于 URL 的路由和基于 cookie 的会话关联。
Azure Web 应用程序防火墙是一种基于云的 Web 应用程序防火墙，有助于保护 Web 应用程序免受常见攻击，例如 SQL 注入和跨站点脚本 (XSS)。
开发运营安全
Azure 提供了多种安全控件来帮助确保 DevOps 流程的安全性，包括 Azure DevOps 和 Azure DevTest Labs。Azure DevOps 提供了一个集中式平台来管理从规划到部署的整个 DevOps 流程，而 Azure DevTest Labs 则为开发人员提供了一个自助服务环境来创建和管理开发和测试环境。
Azure DevOps 还集成了其他 Azure 安全控件，例如 Azure Policy 和 Azure 安全中心，以提供持续的安全评估和合规性。
结论
总之，Azure 提供了一套全面的安全控制，有助于确保部署在 Azure 中的资源的安全性和合规性。这些控制涵盖身份和访问管理、网络安全、数据保护、合规性、应用程序安全和 DevOps 安全。通过适当地理解和实施这些控制，用户可以降低安全漏洞的风险并保护他们在云中的数据和资源。
文章来源： https: //www.c-sharpcorner.com
1683879300
Como migrar funções do Azure de JSDoc JavaScript para TypeScript
Neste tutorial TypeScript - JavaScript, aprenderemos como migrar as funções do Azure de JSDoc JavaScript para TypeScript. Eu implementei isso usando JSDoc JavaScript. Desde então, migrei para TypeScript e achei interessante compartilhar o processo.
Por que migrar de JSDoc JavaScript para TypeScript?
Como os leitores regulares devem saber, sou um grande fã de TypeScript e um grande fã de JSDoc JavaScript. Eu acho que ambos são ótimos. Então, por que migrar de JSDoc JavaScript para TypeScript? Para mim, trata-se principalmente da experiência do desenvolvedor; JSDoc é mais detalhado e o ecossistema mais amplo faz muito mais TypeScript do que JSDoc JavaScript. Portanto, quando você vai além de um aplicativo simples, pelo menos para mim, o TypeScript é uma escolha melhor.
Meu blog é um aplicativo Web estático do Azure com um back-end do Azure Functions. Eu tenho usado JavaScript JSDoc para minhas funções do Azure. Esta postagem pegará o back-end e o migrará para o TypeScript. Já tenho vários recursos que não quero perder ao longo do caminho:
- Eu posso depurar no VS Code
- Eu implanto usando o GitHub Actions
- Tenho testes automatizados usando Jest
Todas essas funcionalidades estão disponíveis para mim com o TypeScript e quero mantê-las. Vamos começar a migrar. Aliás, o código dessa migração está neste PR .
Migrando otsconfig.json
Nosso tsconfig.jsongerencia a maneira como o compilador TypeScript interage com nosso código. Começaremos migrando isto:
``````diff title="tsconfig.json"
{
"compilerOptions": {
- "noEmit": verdadeiro,
- "noEmit": falso,
- "outDir": "dist",
- "rootDir": ".",
"sourceMap": verdadeiro,
"allowJs": falso,
"checkJs": falso,
"moduleResolution": "nó",
}
}
Vejamos as alterações que fizemos:
- Agora estamos emitindo arquivos de nossa compilação graças à noEmitconfiguração false. Não estaremos mais executando o código que escrevemos, mas executaremos o JavaScript que emitimos.
- Estamos especificando um outDirof dist- é aqui que nosso JavaScript compilado será emitido.
- Estamos especificando um rootDirde .- esta é a raiz de nossos arquivos de origem TypeScript.
- Estamos criando mapas de origem para nossos arquivos JavaScript emitidos - isso nos ajudará a depurar nosso código-fonte original. (Mesmo que não o estejamos executando.)
- Não estamos mais permitindo que arquivos JavaScript façam parte de nosso programa, graças à allowJsconfiguração false. (E também não estamos verificando-os graças ao fato de checkJsestarem configurados para false- suspeito que isso esteja implicitamente configurado falsepara allowJsser false- apenas para deixar claro, eu o especifiquei.)
- Estamos especificando um moduleResolutionof node- é assim que o TypeScript procurará um arquivo de um determinado especificador de módulo.
Migrando opackage.json
Para migrar, package.jsonprecisaremos adicionar algumas dependências e ajustar nossos scripts:
```diff title="package.json"
"scripts": {
"build": "tsc",
- "assistir": "tsc -w",
- "prestart": "npm run build", "start": "func start", "test": "jest" }, "devDependencies": { "@azure/functions": "^3.5.0",
- "@types/jest": "^29.2.5",
- "@types/node": "^18.x", "jest": "^29.3.1",
- "ts-jest": "^29.1.0", "typescript": "^5.0.0" } } ```
Estamos adicionando dois scripts:
- watch- isso irá observar nossos arquivos TypeScript e recompilá-los quando eles mudarem - não precisamos disso realmente; mas pode ser útil dependendo do seu fluxo de trabalho preferido.
- prestart- isso será executado antes starte garantirá que nossos arquivos TypeScript sejam compilados e tenhamos JavaScript atualizado para executar.
No nosso devDependencies, estamos adicionando dependências para Jest e Node.js. Também estamos adicionando ts-jesto que nos permitirá executar testes Jest escritos em TypeScript.
Migrando .vscode/settings.jsone.vscode/tasks.json
Mencionei a depuração anteriormente - para fazer isso, precisamos trabalhar nos arquivos settings.jsone tasks.jsonna .vscodepasta. Primeiro o settings.json:
```diff title="configurações.json"
- "azureFunctions.projectLanguage": "JavaScript",
- "azureFunctions.projectLanguage": "TypeScript", ```
O acima é bastante auto-explicativo. Estamos alterando o idioma do nosso projeto Azure Functions de JavaScript para TypeScript. Agora o tasks.json:
```diff title="tasks.json"
{
"version": "2.0.0",
"tasks": [
- {
- "tipo": "concha",
- "label": "npm build (funções)",
- "comando": "npm run build",
- "dependsOn": "npm install (funções)",
- "problemMatcher": "$tsc",
- "opções": {
- "cwd": "${workspaceFolder}/blog-website/api"
- }
- },] } ```
Temos uma nova tarefa aqui que executa nosso npm run buildscript. Isso irá compilar nossos arquivos TypeScript para JavaScript. Também temos um cwdconjunto para blog-website/api- esta é a pasta onde residem nossas funções do Azure - o seu provavelmente será diferente. Juntamente com esse novo script, há alguns ajustes nas tarefas existentes para torná-las dependentes de nossa nova tarefa de compilação:
```diff title="tasks.json"
{
"version": "2.0.0",
"tasks": [
{
"type": "func",
"label": "func: host start",
"command" : "host start",
"problemMatcher": "$func-node-watch",
"isBackground": true,
- "dependsOn": "npm build (funções)",
- "opções": {
- "cwd": "${workspaceFolder}/blog-website/api"
- } }, // ... { "type": "shell", "label": "npm prune (funções)", "command": "npm prune --production",
- "dependsOn": "npm build (funções)", "problemMatcher": [], "options": { "cwd": "${workspaceFolder}/blog-website/api" } } ] } ```
Migrar nossas funções do Azure
Este não será um guia exaustivo de migração de JSDoc JavaScript para TypeScript. Vou me concentrar nas coisas que considero mais relevantes para o Azure Functions. Vamos começar com o fallback/function.jsonarquivo que alimenta nossos redirecionamentos dinâmicos e reside em /api/fallback:
```diff title="fallback/function.json"
{
"bindings": [
{
"authLevel": "anonymous",
"type": "httpTrigger",
"direction": "in",
"name": "req ",
"methods": ["get", "post"]
},
{
"type": "http",
"direction": "out",
"name": "res"
}
],
- "scriptFile": "../dist/fallback/index.js" } ```
Há uma adição aqui, para apontar novamente scriptFilepara o JavaScript compilado.
Agora vamos ver o código da função. Originalmente um arquivo JavaScript chamado index.js; deve ser renomeado para index.ts. O código original ficou assim:
```js title="fallback/index.js"
const redirect = require('./redirect');
const saveToDatabase = require('./saveToDatabase');
/**
*
- @param { import("@azure/functions").Context } contexto
- @param { import("@azure/functions").HttpRequest } req */ função async fallback(context, req) { //... }
module.exports = fallback;
After renaming to `index.ts` and adding some TypeScript types, it looks like this:
```ts title="fallback/index.ts"
import type { AzureFunction, Context, HttpRequest } from '@azure/functions';
import { redirect } from './redirect';
import { saveToDatabase } from './saveToDatabase';
const httpTrigger: AzureFunction = async function (
context: Context,
req: HttpRequest
): Promise<void> {
//...
};
export default httpTrigger;Como podemos ver, a importação de tipos se torna muito mais sucinta. Também estamos exportando a função como defaultem vez de module.exports. Isso ocorre porque estamos usando módulos ES em vez de módulos CommonJS para autoria. Também podemos ver que estamos usando importem vez de requireimportar nossas funções. Embora o CommonJS seja mais direto de usar, a sintaxe dos Módulos ES parece muito mais agradável de usar; pelo menos para mim. (Vale a pena notar que não estamos usando ES Modules em nosso JavaScript compilado - ainda estamos usando CommonJS lá; mas não precisamos pensar nisso quando estamos escrevendo nosso código.)
Não vou passar pela migração dos outros arquivos, mas o processo é o mesmo. Renomeie o arquivo para .ts, adicione tipos TypeScript e use importem vez de require.
Migrando nossos testes
Estamos praticamente na reta final agora; só precisamos migrar nossos testes. Vamos começar com o jest.config.js:
```diff title="jest.config.js"
- predefinição: 'ts-is',
- testPathIgnorePatterns: ['/node_modules/', '/dist/'], ```
Estamos adicionando um presetdos ts-jestquais nos permitirá executar testes TypeScript. Se você se lembra, adicionamos a ts-jestdependência anteriormente; foi para isso.
Também estamos adicionando distao nosso testPathIgnorePatterns- isso porque não queremos executar nossos testes em nosso JavaScript compilado - acabaríamos executando os testes duas vezes sem isso.
Vamos voltar nossa atenção para os testes diretamente. Novamente, fazemos a renomeação clássica de .jspara .ts, e nossas importações se tornam mais concisas e mais ES Module-y:
```diff title="redirect.test.ts"
-/**
- * @typedef { import("@azure/functions").Logger } Logger
- */ +import type { Logger } from '@azure/functions'; -const { descrever, esperar, testar } = require('@jest/globals'); +import {descrever, esperar, testar} de '@jest/globals'; -const redirecionamento = require('./redirecionamento'); +importar { redirecionar } de './redirecionar'; ```
Lindo. Finalmente, temos alguns ajustes no código dos próprios testes. Em primeiro lugar, declarar nosso mock fica muito mais fácil:
```diff title="redirect.test.ts"
-/** @type {jest.Mock} */ const mockLogger = jest.fn();
+const mockLogger: jest.Mock = jest.fn();
Secondly, casting our mock to the type we want is much more straightforward:
```diff title="redirect.test.ts"
-/** @type {any} */ (mockLogger)
+mockLogger as unknown as LoggerNão sei como aslançar duas vezes no JSDoc - e agora não preciso.
Conclusão
Agora temos uma base de código TypeScript Azure Functions, com todos os recursos de depuração/teste/implantação que tínhamos antes. Não tivemos que fazer nada em relação à implantação, porque simplesmente funciona™️. Espero que este post tenha sido útil para você!
Fonte do artigo: https://dev.to
1683874020
Управление безопасностью Azure — управление идентификацией и доступом
В этом руководстве по Azure мы узнаем о Azure Security Control — управлении идентификацией и доступом.
Элементы управления безопасностью Azure
Azure — это служба облачных вычислений от Microsoft, которая предлагает широкий спектр инструментов и служб для создания, развертывания и управления приложениями и службами в облаке. Как и в случае с любой облачной службой, безопасность является главной заботой пользователей. В этой статье мы обсудим элементы управления безопасностью, предлагаемые Azure для обеспечения конфиденциальности, целостности и доступности пользовательских данных.
Управление доступом
Управление доступом — это один из основных элементов управления безопасностью в Azure. Azure Active Directory (AD) — это служба управления идентификацией и доступом, которая обеспечивает безопасный доступ к ресурсам в Azure. Он позволяет администраторам управлять идентификацией пользователей, разрешениями на доступ и настройками многофакторной аутентификации.
Azure AD также поддерживает интеграцию с внешними поставщиками удостоверений, такими как службы федерации Active Directory (ADFS), чтобы пользователи могли проходить аутентификацию, используя свои локальные учетные данные.
Сетевая безопасность
Azure предоставляет несколько элементов управления сетевой безопасностью для защиты ресурсов и данных в облаке. Брандмауэр Azure — это служба сетевой безопасности, предоставляющая возможности брандмауэра с отслеживанием состояния для входящего и исходящего трафика. Он позволяет администраторам создавать и применять политики сетевой безопасности на основе приложений, портов и протоколов.
Виртуальная сеть Azure (VNet) — это частная сеть, которая позволяет пользователям создавать изолированные сетевые среды в облаке. Он поддерживает различные функции сетевой безопасности, в том числе группы сетевой безопасности (NSG), которые позволяют администраторам фильтровать сетевой трафик на основе исходного и конечного IP-адресов, портов и протоколов.
Защита данных
Azure предлагает широкий спектр функций защиты данных для защиты данных, хранящихся в облаке. Служба хранилища Azure предоставляет различные варианты хранения данных, включая хранилище BLOB-объектов, файлов и очередей, с различными механизмами защиты данных, такими как шифрование при хранении и передаче.
Azure Key Vault — это облачная служба, которая позволяет пользователям безопасно хранить криптографические ключи, сертификаты и секреты, используемые в приложениях и службах, и управлять ими. Он предоставляет решение для централизованного управления ключами с политиками контроля доступа и журналами аудита.
Соответствие и управление
Azure предоставляет функции соответствия и управления, помогающие пользователям соблюдать нормативные требования и требования соответствия. Политика Azure — это служба, которая позволяет администраторам создавать и применять политики для ресурсов, развернутых в Azure. Это позволяет пользователям убедиться, что ресурсы настроены в соответствии со стандартами организации и нормативными требованиями.
Центр безопасности Azure — это унифицированное решение для управления безопасностью, которое обеспечивает видимость и контроль над безопасностью в среде Azure. Он предлагает непрерывную оценку безопасности, обнаружение угроз и рекомендации по исправлению.
В заключение следует отметить, что Azure предоставляет надежные элементы управления безопасностью для обеспечения конфиденциальности, целостности и доступности пользовательских данных. Элементы управления безопасностью, обсуждаемые в этой статье, — это лишь некоторые из многих функций, предлагаемых Azure. Пользователи должны понимать эти элементы управления и применять их надлежащим образом для защиты своих ресурсов и данных в облаке.
Шифрование
Шифрование является важным средством обеспечения безопасности для защиты данных как в состоянии покоя, так и при передаче. Azure предлагает различные варианты шифрования для защиты данных, такие как шифрование диска Azure и шифрование службы хранилища Azure. Шифрование дисков Azure помогает защитить данные на виртуальных машинах Azure, шифруя ОС и диски данных. Шифрование службы хранилища Azure шифрует данные, хранящиеся в неактивных учетных записях хранилища Azure.
Кроме того, Azure Key Vault также поддерживает аппаратные модули безопасности (HSM), чтобы обеспечить более безопасное и защищенное от несанкционированного доступа хранение ключей и криптографические операции.
Защита от угроз
Центр безопасности Azure — это ключевое решение для управления безопасностью в Azure, которое помогает защититься от угроз и уязвимостей. Он обеспечивает единое представление о безопасности в среде Azure и помогает выявлять и устранять угрозы безопасности в режиме реального времени.
Центр безопасности Azure интегрируется с Azure Log Analytics, которая собирает и анализирует данные журналов из различных служб и ресурсов Azure. Центр безопасности Azure использует эти данные для предоставления сведений об угрозах, обнаружения аномалий и создания предупреждений при обнаружении подозрительных действий.
Мониторинг и аудит
Azure provides monitoring and auditing capabilities to help users track and review activity in their environment. Azure Monitor is a service that collects and analyzes telemetry data from various Azure resources and services. It provides a centralized location for monitoring and alerting on events and metrics across the environment.
Azure Audit Logs provide detailed information about changes made to resources in Azure. This information includes who made the change, what was changed, and when the change occurred. Azure Audit Logs can help with compliance and regulatory requirements by providing an auditable record of activity in the environment.
Audit Logging Feature In Azure
Disaster Recovery
Disaster recovery is an important aspect of business continuity planning. Azure provides various options for disaster recovery, such as Azure Site Recovery, which is a disaster recovery solution for virtual machines, and Azure Backup, which provides backup and restore capabilities for data stored in Azure.
Azure also offers Geo-redundant storage, which replicates data to a secondary region to provide high availability and disaster recovery capabilities. Users can choose from different replication options, such as LRS (Locally Redundant Storage), ZRS (Zone Redundant Storage), and GRS (Geo-Redundant Storage).
In conclusion, Azure provides a comprehensive set of security controls that help ensure the confidentiality, integrity, and availability of user data. Implementing these controls appropriately can help users safeguard their resources and data in the cloud.
Identity and Access Management
Azure offers a robust identity and access management (IAM) system that provides granular control over access to Azure resources. With Azure IAM, administrators can grant access to resources based on users' roles and responsibilities, reducing the risk of unauthorized access.
Azure also supports multi-factor authentication (MFA) for additional security. This requires users to provide additional proof of their identity, such as a phone call or text message, before accessing resources.
Compliance
Azure offers compliance certifications and audit reports that demonstrate Azure's compliance with various industry regulations and standards, such as ISO 27001, HIPAA, and PCI DSS. These certifications and reports provide independent assurance that Azure meets rigorous security and compliance standards.
Azure also provides compliance tools, such as Azure Policy, which helps users create and enforce compliance policies, and Azure Security Center, which provides continuous monitoring and compliance assessments.
Application Security
Azure provides several security controls to help secure applications deployed in Azure. Azure Application Gateway is a web traffic load balancer that offers layer 7 load balancing and application delivery features, such as SSL offloading, URL-based routing, and cookie-based session affinity.
Azure Web Application Firewall is a cloud-based web application firewall that helps protect web applications from common attacks, such as SQL injection and cross-site scripting (XSS).
DevOps Security
Azure offers several security controls that help ensure the security of the DevOps process, including Azure DevOps and Azure DevTest Labs. Azure DevOps provides a centralized platform for managing the entire DevOps process, from planning to deployment, while Azure DevTest Labs provides a self-service environment for developers to create and manage development and testing environments.
Azure DevOps also integrates with other Azure security controls, such as Azure Policy and Azure Security Center, to provide continuous security assessment and compliance.
Conclusion
В заключение следует отметить, что Azure предоставляет полный набор элементов управления безопасностью, которые помогают обеспечить безопасность и соответствие требованиям ресурсов, развернутых в Azure. Эти элементы управления охватывают управление идентификацией и доступом, сетевую безопасность, защиту данных, соответствие требованиям, безопасность приложений и безопасность DevOps. Поняв и правильно внедрив эти элементы управления, пользователи могут снизить риск нарушений безопасности и защитить свои данные и ресурсы в облаке.
Источник статьи: https://www.c-sharpcorner.com
1683857280
Escolha um serviço de armazenamento do Azure
Neste tutorial do Azure, aprenderemos como escolher o serviço de armazenamento do Azure certo?. O Armazenamento do Azure é a solução de armazenamento baseada em nuvem da Microsoft. Ele vai além do armazenamento de arquivos tradicional, oferecendo uma gama abrangente de serviços de armazenamento modernos. Este artigo irá explorar os vários serviços disponíveis e seus casos de uso específicos, permitindo que você selecione o serviço que melhor atende às suas necessidades.
Armazenamento de Blobs do Azure: armazenamento de dados não estruturados com facilidade
O Armazenamento de Blob do Azure é um serviço de armazenamento poderoso e escalonável projetado especificamente para armazenar dados não estruturados. Sejam imagens, vídeos, documentos, backups, logs ou qualquer outro tipo de arquivo, o Blob Storage oferece uma solução econômica e confiável para gerenciar grandes quantidades de dados na nuvem.
Casos de uso do Armazenamento de Blobs do Azure
- Distribuição de mídia e conteúdo: armazene e veicule com eficiência imagens, vídeos e arquivos de áudio para redes de distribuição de conteúdo (CDNs) e plataformas de streaming de mídia.
- Backup e recuperação de desastres: armazene e acesse backups com segurança, garantindo a proteção dos dados e facilitando a recuperação de desastres.
- Arquivamento de dados: Cumpra os requisitos regulatórios arquivando dados de maneira econômica para fins históricos e de retenção de longo prazo.
- Armazenamento de dados de log e IoT: lide com a ingestão e armazenamento de alto rendimento de dados de log e telemetria de IoT para análise em tempo real e análise histórica.
- Armazenamento distribuído de aplicativos: serve como um repositório central para dados compartilhados entre aplicativos distribuídos, facilitando a colaboração e a troca eficiente de dados.
- Migração e Importação/Exportação de Dados: Simplifique a migração de dados para a nuvem e transfira grandes volumes de dados por meio de remessa física usando o serviço de Importação/Exportação.
Arquivos do Azure: compartilhamento de arquivos de alto desempenho na nuvem
Os Arquivos do Azure são usados para configurar um sistema de arquivos compartilhado entre as VMs. O Network File Share permite que você centralize o armazenamento de arquivos, fornecendo um único local onde vários usuários ou sistemas podem acessar e colaborar em arquivos. Isso simplifica o gerenciamento de arquivos e elimina a necessidade de cópias de arquivos individuais ou locais de armazenamento dispersos.
Diferença entre o Armazenamento de Blobs do Azure e os Arquivos do Azure
Blob Storage é projetado para armazenar dados não estruturados, como imagens e vídeos, e é acessado por meio de APIs REST. Por outro lado, o Azure Files fornece armazenamento em nível de arquivo, suportando protocolos SMB e NFS para acesso compartilhado a dados estruturados, tornando-o adequado para cenários de sistema de arquivos tradicionais e fácil integração com aplicativos existentes.
Tabelas do Azure: armazenamento de valor-chave NoSQL para aplicativos escalonáveis
O Azure Tables é um serviço de armazenamento de valor-chave NoSQL. Ele foi projetado para lidar com grandes quantidades de dados estruturados de maneira altamente escalável e eficiente. Ele fornece um esquema flexível, tempos de acesso rápidos e dimensionamento automático, tornando-o ideal para criar aplicativos que requerem armazenamento de dados rápido e escalável. Para obter mais informações sobre como começar com o Armazenamento de Tabelas do Azure, leia Introdução ao Armazenamento de Tabelas do Azure
Casos de uso
- Aplicativos da Web e armazenamento de dados do usuário.
- Ingestão e análise de dados IoT.
- Gerenciamento de registro e trilha de auditoria.
- Sistemas de gerenciamento de conteúdo (CMS) e armazenamento de conteúdo estruturado.
- Armazenamento e indexação de metadados.
Filas do Azure: mensagens confiáveis para aplicativos escalonáveis
O Azure Queues é um serviço de mensagens que oferece comunicação assíncrona e confiável entre componentes de aplicativos distribuídos. Ele fornece uma solução simples e escalável para desacoplar serviços, garantindo a entrega confiável de mensagens e permitindo o processamento eficiente de cargas de trabalho. Ele não oferece suporte a tópicos, você deve ir para o Barramento de Serviço do Azure.
Abaixo estão alguns casos de uso em que as filas ajudam você:
- Descarregamento de tarefas e filas de trabalho para processamento assíncrono.
- Arquiteturas e notificações orientadas a eventos.
- Comunicação confiável entre componentes em aplicativos distribuídos.
- Processamento prioritário para tarefas urgentes ou importantes.
- Buffering e nivelamento de carga para lidar com picos de carga de trabalho.
- Orquestração e coordenação do fluxo de trabalho.
Fonte do artigo: https://www.c-sharpcorner.com
1683814140
Controle de Segurança do Azure - Controle de Acesso e Identidade
Neste tutorial do Azure, aprenderemos sobre o controle de segurança do Azure - controle de identidade e acesso.
Controles de segurança do Azure
O Azure é um serviço de computação em nuvem da Microsoft que oferece uma ampla variedade de ferramentas e serviços para criar, implantar e gerenciar aplicativos e serviços na nuvem. Como em qualquer serviço em nuvem, a segurança é uma preocupação primordial para os usuários. Neste artigo, discutiremos os controles de segurança oferecidos pelo Azure para garantir a confidencialidade, integridade e disponibilidade dos dados do usuário.
Gerenciamento de acesso
O gerenciamento de acesso é um dos controles de segurança fundamentais no Azure. Azure Active Directory (AD) é o serviço de gerenciamento de acesso e identidade que fornece acesso seguro aos recursos no Azure. Ele permite que os administradores gerenciem identidades de usuários, permissões de acesso e configurações de autenticação multifator.
O Azure AD também oferece suporte à integração com provedores de identidade externos, como Active Directory Federation Services (ADFS), para permitir que os usuários façam a autenticação usando suas credenciais locais.
Segurança de rede
O Azure fornece vários controles de segurança de rede para proteger recursos e dados na nuvem. O Firewall do Azure é um serviço de segurança de rede que fornece recursos de firewall com monitoramento de estado para tráfego de entrada e saída. Ele permite que os administradores criem e imponham políticas de segurança de rede com base no aplicativo, porta e protocolo.
A Rede Virtual do Azure (VNet) é uma rede privada que permite aos usuários criar ambientes de rede isolados na nuvem. Ele oferece suporte a vários recursos de segurança de rede, incluindo grupos de segurança de rede (NSGs) que permitem aos administradores filtrar o tráfego de rede com base em endereços IP de origem e destino, portas e protocolos.
Proteção de dados
O Azure oferece uma ampla variedade de recursos de proteção de dados para proteger os dados armazenados na nuvem. O armazenamento do Azure fornece diferentes tipos de opções de armazenamento de dados, incluindo armazenamento de Blob, arquivo e fila, com vários mecanismos de proteção de dados, como criptografia em repouso e em trânsito.
Azure Key Vault é um serviço baseado em nuvem que permite aos usuários armazenar e gerenciar com segurança chaves criptográficas, certificados e segredos usados em aplicativos e serviços. Ele fornece uma solução centralizada de gerenciamento de chaves com políticas de controle de acesso e logs de auditoria.
Conformidade e Governança
O Azure fornece recursos de conformidade e governança para ajudar os usuários a atender aos requisitos regulamentares e de conformidade. Azure Policy é um serviço que permite aos administradores criar e impor políticas para recursos implantados no Azure. Ele permite que os usuários garantam que os recursos sejam configurados de acordo com os padrões organizacionais e requisitos regulatórios.
A Central de Segurança do Azure é uma solução de gerenciamento de segurança unificada que fornece visibilidade e controle sobre a segurança em todo o ambiente do Azure. Ele oferece avaliação contínua de segurança, detecção de ameaças e recomendações de correção.
Concluindo, o Azure fornece controles de segurança robustos para garantir a confidencialidade, integridade e disponibilidade dos dados do usuário. Os controles de segurança discutidos neste artigo são apenas alguns dos muitos recursos oferecidos pelo Azure. Os usuários devem entender esses controles e implementá-los adequadamente para proteger seus recursos e dados na nuvem.
Criptografia
A criptografia é um controle de segurança crucial para proteger os dados em repouso e em trânsito. O Azure oferece várias opções de criptografia para proteger os dados, como Azure Disk Encryption e Azure Storage Service Encryption. A Criptografia de Disco do Azure ajuda a proteger os dados nas Máquinas Virtuais do Azure criptografando o sistema operacional e os discos de dados. A criptografia do serviço de armazenamento do Azure criptografa dados armazenados em contas de armazenamento do Azure em repouso.
Além disso, o Azure Key Vault também oferece suporte a módulos de segurança de hardware (HSMs) para fornecer armazenamento de chaves e operações criptográficas mais seguros e à prova de adulteração.
Proteção contra ameaças
A Central de Segurança do Azure é uma solução de gerenciamento de segurança chave no Azure que ajuda a proteger contra ameaças e vulnerabilidades. Ele fornece uma visão unificada da segurança em todo o ambiente do Azure e pode ajudar a identificar e mitigar as ameaças de segurança em tempo real.
A Central de Segurança do Azure integra-se ao Azure Log Analytics, que coleta e analisa dados de log de vários serviços e recursos do Azure. A Central de Segurança do Azure usa esses dados para fornecer inteligência de ameaças, detectar anomalias e gerar alertas quando atividades suspeitas são detectadas.
Monitoramento e Auditoria
O Azure fornece recursos de monitoramento e auditoria para ajudar os usuários a rastrear e revisar a atividade em seu ambiente. Azure Monitor é um serviço que coleta e analisa dados de telemetria de vários recursos e serviços do Azure. Ele fornece um local centralizado para monitoramento e alerta sobre eventos e métricas em todo o ambiente.
Os logs de auditoria do Azure fornecem informações detalhadas sobre as alterações feitas nos recursos do Azure. Essas informações incluem quem fez a alteração, o que foi alterado e quando ocorreu a alteração. Os logs de auditoria do Azure podem ajudar com os requisitos regulamentares e de conformidade, fornecendo um registro auditável da atividade no ambiente.
Recuperação de desastres
A recuperação de desastres é um aspecto importante do planejamento de continuidade de negócios. O Azure fornece várias opções para recuperação de desastres, como o Azure Site Recovery, que é uma solução de recuperação de desastres para máquinas virtuais, e o Azure Backup, que fornece recursos de backup e restauração para dados armazenados no Azure.
O Azure também oferece armazenamento com redundância geográfica, que replica dados para uma região secundária para fornecer recursos de alta disponibilidade e recuperação de desastres. Os usuários podem escolher entre diferentes opções de replicação, como LRS (Armazenamento com redundância local), ZRS (Armazenamento com redundância de zona) e GRS (Armazenamento com redundância geográfica).
Concluindo, o Azure fornece um conjunto abrangente de controles de segurança que ajudam a garantir a confidencialidade, integridade e disponibilidade dos dados do usuário. A implementação adequada desses controles pode ajudar os usuários a proteger seus recursos e dados na nuvem.
Gerenciamento de identidade e acesso
O Azure oferece um sistema robusto de gerenciamento de identidade e acesso (IAM) que fornece controle granular sobre o acesso aos recursos do Azure. Com o Azure IAM, os administradores podem conceder acesso a recursos com base nas funções e responsabilidades dos usuários, reduzindo o risco de acesso não autorizado.
O Azure também oferece suporte à autenticação multifator (MFA) para segurança adicional. Isso exige que os usuários forneçam provas adicionais de sua identidade, como uma chamada telefônica ou mensagem de texto, antes de acessar os recursos.
Conformidade
O Azure oferece certificações de conformidade e relatórios de auditoria que demonstram a conformidade do Azure com vários regulamentos e padrões do setor, como ISO 27001, HIPAA e PCI DSS. Essas certificações e relatórios fornecem garantia independente de que o Azure atende a padrões rigorosos de segurança e conformidade.
O Azure também fornece ferramentas de conformidade, como o Azure Policy, que ajuda os usuários a criar e impor políticas de conformidade, e o Azure Security Center, que fornece monitoramento contínuo e avaliações de conformidade.
Segurança de aplicativos
O Azure fornece vários controles de segurança para ajudar a proteger os aplicativos implantados no Azure. O Azure Application Gateway é um balanceador de carga de tráfego da Web que oferece balanceamento de carga de camada 7 e recursos de entrega de aplicativos, como descarregamento de SSL, roteamento baseado em URL e afinidade de sessão baseada em cookie.
O Azure Web Application Firewall é um firewall de aplicativo Web baseado em nuvem que ajuda a proteger aplicativos Web contra ataques comuns, como injeção de SQL e script entre sites (XSS).
Segurança DevOps
O Azure oferece vários controles de segurança que ajudam a garantir a segurança do processo DevOps, incluindo Azure DevOps e Azure DevTest Labs. O Azure DevOps fornece uma plataforma centralizada para gerenciar todo o processo de DevOps, desde o planejamento até a implantação, enquanto o Azure DevTest Labs fornece um ambiente de autoatendimento para que os desenvolvedores criem e gerenciem ambientes de desenvolvimento e teste.
O Azure DevOps também se integra a outros controles de segurança do Azure, como Azure Policy e Azure Security Center, para fornecer conformidade e avaliação de segurança contínuas.
Conclusão
Concluindo, o Azure fornece um conjunto abrangente de controles de segurança que ajudam a garantir a segurança e a conformidade dos recursos implantados no Azure. Esses controles abrangem gerenciamento de identidade e acesso, segurança de rede, proteção de dados, conformidade, segurança de aplicativos e segurança de DevOps. Ao entender e implementar esses controles adequadamente, os usuários podem reduzir o risco de violações de segurança e proteger seus dados e recursos na nuvem.
Fonte do artigo: https://www.c-sharpcorner.com
1683807660
Cách di chuyển các hàm Azure từ JSDoc JavaScript sang TypeScript
Trong hướng dẫn TypeScript - JavaScript này, chúng ta sẽ tìm hiểu về Cách di chuyển các hàm Azure từ JSDoc JavaScript sang TypeScript. Tôi đã triển khai điều này bằng cách sử dụng JSDoc JavaScript. Kể từ đó, tôi đã chuyển nó sang TypeScript và tôi nghĩ sẽ rất thú vị khi chia sẻ quy trình này.
Tại sao lại di chuyển từ JSDoc JavaScript sang TypeScript?
Như những độc giả thường xuyên sẽ biết, tôi vừa là một fan hâm mộ lớn của TypeScript vừa là một fan hâm mộ lớn của JSDoc JavaScript. Tôi nghĩ cả hai đều tuyệt vời. Vậy tại sao lại chuyển từ JSDoc JavaScript sang TypeScript? Đối với tôi, chủ yếu là về trải nghiệm của nhà phát triển; JSDoc dài dòng hơn và hệ sinh thái rộng lớn hơn thực hiện nhiều TypeScript hơn so với JSDoc JavaScript. Vì vậy, khi bạn vượt ra ngoài một ứng dụng đơn giản, ít nhất đối với tôi, TypeScript là một lựa chọn tốt hơn.
Blog của tôi là một Ứng dụng web tĩnh Azure với phần cuối của Chức năng Azure. Tôi đã và đang sử dụng JSDoc JavaScript cho các Chức năng Azure của mình. Bài đăng này sẽ lấy phần cuối và chuyển nó sang TypeScript. Có nhiều khả năng chi trả khác nhau mà tôi đã có sẵn mà tôi không muốn đánh mất trên đường đi:
- Tôi có thể gỡ lỗi trong Mã VS
- Tôi triển khai bằng GitHub Actions
- Tôi có các bài kiểm tra tự động tại chỗ bằng cách sử dụng Jest
Tất cả những khả năng chi trả này đều có sẵn cho tôi với TypeScript và tôi muốn giữ chúng. Hãy bắt đầu di chuyển. Ngẫu nhiên, mã cho quá trình di chuyển này nằm trong PR này .
Di chuyển cáctsconfig.json
Chúng tôi tsconfig.jsonquản lý cách trình biên dịch TypeScript tương tác với mã của chúng tôi. Chúng tôi sẽ bắt đầu bằng cách di chuyển cái này:
``````diff title="tsconfig.json"
{
"compilerOptions": {
- "noEmit": đúng,
- "noEmit": sai,
- "outDir": "khu vực",
- "rootDir": ".",
"bản đồ nguồn": đúng,
"allowJs": sai,
"checkJs": sai,
"moduleResolution": "nút",
}
}
Hãy xem những thay đổi chúng tôi đã thực hiện:
- Chúng tôi hiện đang phát các tệp từ phần tổng hợp của mình nhờ được noEmitđặt thành false. Chúng tôi sẽ không thực sự chạy mã mà chúng tôi viết nữa, nhưng chúng tôi sẽ chạy JavaScript mà chúng tôi phát ra.
- Chúng tôi đang chỉ định một outDirtrong số dist- đây là nơi JavaScript đã biên dịch của chúng tôi sẽ được phát ra.
- Chúng tôi đang chỉ định một rootDirtrong số .- đây là thư mục gốc của các tệp nguồn TypeScript của chúng tôi.
- Chúng tôi đang tạo bản đồ nguồn cho các tệp JavaScript được phát ra - điều này sẽ giúp chúng tôi gỡ lỗi mã nguồn ban đầu của mình. (Mặc dù chúng tôi không chạy nó.)
- Chúng tôi không còn cho phép các tệp JavaScript là một phần của chương trình của chúng tôi nhờ được allowJsđặt thành false. (Và chúng tôi cũng không kiểm tra chúng nhờ được checkJsđặt thành false- tôi nghi ngờ điều này hoàn toàn được đặt falsethành allowJs- falsechỉ để rõ ràng là tôi đã chỉ định nó.)
- Chúng tôi đang chỉ định một moduleResolutiontrong số node- đây là cách TypeScript sẽ tra cứu tệp từ một trình xác định mô-đun nhất định.
Di chuyển cácpackage.json
Để di chuyển, package.jsonchúng tôi sẽ cần thêm một số phụ thuộc và chỉnh sửa tập lệnh của mình:
```diff title="package.json"
"scripts": {
"build": "tsc",
- "xem": "tsc -w",
- "prestart": "npm run build", "start": "func start", "test": "jest" }, "devDependencies": { "@azure/functions": "^3.5.0",
- "@types/jest": "^29.2.5",
- "@types/node": "^18.x", "jest": "^29.3.1",
- "ts-jest": "^29.1.0", "typescript": "^5.0.0" } } ```
Chúng tôi đang thêm hai tập lệnh:
- watch- điều này sẽ xem các tệp TypeScript của chúng tôi và biên dịch lại chúng khi chúng thay đổi - chúng tôi thực sự không cần điều này; nhưng nó có thể hữu ích tùy thuộc vào quy trình làm việc ưa thích của bạn.
- prestart- điều này sẽ chạy trước startvà sẽ đảm bảo các tệp TypeScript của chúng tôi được biên dịch và chúng tôi có JavaScript cập nhật để chạy.
Trong phần của chúng tôi, devDependencieschúng tôi đang thêm các phụ thuộc cho Jest và Node.js. Chúng tôi cũng đang thêm tính năng ts-jestnày sẽ cho phép chúng tôi chạy các bài kiểm tra Jest được viết bằng TypeScript.
Di cư .vscode/settings.jsonvà.vscode/tasks.json
Tôi đã đề cập đến việc gỡ lỗi trước đó - để có được điều đó, chúng ta cần làm việc trên các tệp settings.jsonvà tasks.jsontrong .vscodethư mục. Đầu tiên settings.json:
```diff title="settings.json"
- "azureFunctions.projectLanguage": "JavaScript",
- "azureFunctions.projectLanguage": "TypeScript", ```
Ở trên là khá tự giải thích. Chúng tôi đang thay đổi ngôn ngữ của dự án Azure Functions từ JavaScript sang TypeScript. Bây giờ tasks.json:
```diff title="tasks.json"
{
"phiên bản": "2.0.0",
"tác vụ": [
- {
- "loại": "vỏ",
- "nhãn": "bản dựng npm (chức năng)",
- "lệnh": "npm run build",
- "phụ thuộc vào": "cài đặt npm (chức năng)",
- "problemMatcher": "$tsc",
- "tùy chọn": {
- "cwd": "${workspaceFolder}/blog-website/api"
- }
- }, ] } ```
Chúng tôi đã có một nhiệm vụ mới tại đây để chạy npm run buildtập lệnh của chúng tôi. Điều này sẽ biên dịch các tệp TypeScript của chúng tôi thành JavaScript. Chúng tôi cũng đã thiết cwdlập để blog-website/api- đây là thư mục chứa các Hàm Azure của chúng tôi - thư mục của bạn có thể sẽ khác. Bên cạnh tập lệnh mới này, có một số điều chỉnh đối với các tác vụ hiện có để làm cho chúng phụ thuộc vào tác vụ xây dựng mới của chúng tôi:
```diff title="tasks.json"
{
"version": "2.0.0",
"tasks": [
{
"type": "func",
"label": "func: host start",
"command" : "bắt đầu máy chủ",
"problemMatcher": "$func-node-watch",
"isBackground": true,
- "phụ thuộc vào": "bản dựng npm (chức năng)",
- "tùy chọn": {
- "cwd": "${workspaceFolder}/blog-website/api"
- } }, // ... { "type": "shell", "label": "npm prune (functions)", "command": "npm prune --production",
- "dependsOn": "npm build (functions)", "problemMatcher": [], "options": { "cwd": "${workspaceFolder}/blog-website/api" } } ] } ```
Di chuyển các chức năng Azure của chúng tôi
Đây sẽ không phải là hướng dẫn đầy đủ về việc di chuyển từ JSDoc JavaScript sang TypeScript. Tôi sẽ tập trung vào những thứ mà tôi thấy phù hợp nhất với Azure Functions. Hãy bắt đầu với fallback/function.jsontệp cung cấp năng lượng cho các chuyển hướng động của chúng tôi và tồn tại tại /api/fallback:
```diff title="fallback/function.json"
{
"bindings": [
{
"authLevel": "anonymous",
"type": "httpTrigger",
"direction": "in",
"name": "req ",
"phương thức": ["get", "post"]
},
{
"type": "http",
"direction": "out",
"name": "res"
}
],
- "scriptFile": "../dist/fallback/index.js" } ```
Có một bổ sung ở đây, để trỏ lại scriptFileJavaScript đã biên dịch.
Bây giờ hãy xem mã cho chức năng. Ban đầu là một tệp JavaScript có tên index.js; nó phải được đổi tên thành index.ts. Mã ban đầu trông như thế này:
```js title="fallback/index.js"
const redirect = require('./redirect');
const saveToDatabase = require('./saveToDatabase');
/**
*
- @param { nhập("@azure/functions").Context } bối cảnh
- @param { nhập("@azure/functions").HttpRequest } req */ dự phòng hàm async(bối cảnh, req) { //... }
module.exports = dự phòng;
After renaming to `index.ts` and adding some TypeScript types, it looks like this:
```ts title="fallback/index.ts"
import type { AzureFunction, Context, HttpRequest } from '@azure/functions';
import { redirect } from './redirect';
import { saveToDatabase } from './saveToDatabase';
const httpTrigger: AzureFunction = async function (
context: Context,
req: HttpRequest
): Promise<void> {
//...
};
export default httpTrigger;Như chúng ta có thể thấy, kiểu nhập trở nên ngắn gọn hơn nhiều. Chúng tôi cũng đang xuất hàm dưới defaultdạng module.exports. Điều này là do chúng tôi đang sử dụng Mô-đun ES thay vì mô-đun CommonJS để soạn thảo. Chúng tôi cũng có thể thấy rằng chúng tôi đang sử dụng importthay vì requirenhập chức năng của mình. Trong khi CommonJS dễ sử dụng hơn, cú pháp cho các Mô-đun ES dễ sử dụng hơn nhiều; ít nhất cho tôi. (Điều đáng chú ý là chúng tôi không sử dụng Mô-đun ES trong JavaScript đã biên dịch của mình - chúng tôi vẫn đang sử dụng CommonJS ở đó; nhưng chúng tôi không cần nghĩ về điều đó khi viết mã của mình.)
Tôi sẽ không hướng dẫn việc di chuyển các tệp khác, nhưng quá trình này giống nhau. Đổi tên tệp thành .ts, thêm các loại TypeScript và sử dụng importthay vì require.
Di chuyển các bài kiểm tra của chúng tôi
Bây giờ chúng tôi đang ở gần nhà; chúng ta chỉ cần di chuyển các bài kiểm tra của mình. Hãy bắt đầu với jest.config.js:
```diff title="jest.config.js"
- đặt trước: 'ts-is',
- testPathIgnorePatterns: ['/node_modules/', '/dist/'], ```
Chúng tôi đang thêm một presettrong số ts-jestđó sẽ cho phép chúng tôi chạy thử nghiệm TypeScript. Nếu bạn nhớ lại, chúng tôi đã thêm ts-jestphần phụ thuộc trước đó; nó dành cho việc này.
Chúng tôi cũng đang bổ sung thêm dist- testPathIgnorePatternsđiều này là do chúng tôi không muốn chạy thử nghiệm đối với JavaScript đã biên dịch của mình - chúng tôi sẽ chạy thử nghiệm hai lần nếu không có điều này.
Hãy chuyển sự chú ý của chúng tôi đến các bài kiểm tra trực tiếp. Một lần nữa, chúng tôi thực hiện đổi tên cổ điển từ .jsthành .tsvà quá trình nhập của chúng tôi trở nên ngắn gọn hơn và nhiều hơn Mô-đun ES-y:
```diff title="redirect.test.ts"
-/**
- * @typedef { nhập("@azure/functions").Logger } Logger
- */ +loại nhập { Logger } từ '@azure/functions'; -const { mô tả, mong đợi, kiểm tra } = yêu cầu('@jest/globals'); +nhập {mô tả, mong đợi, kiểm tra} từ '@jest/globals'; -const chuyển hướng = yêu cầu('./redirect'); +nhập {chuyển hướng} từ './redirect'; ```
Xinh đẹp. Cuối cùng, chúng tôi đã có một số điều chỉnh đối với mã của các bài kiểm tra. Đầu tiên, việc khai báo giả của chúng ta trở nên dễ dàng hơn nhiều:
```diff title="redirect.test.ts"
-/** @type {jest.Mock} */ const mockLogger = jest.fn();
+const mockLogger: jest.Mock = jest.fn();
Secondly, casting our mock to the type we want is much more straightforward:
```diff title="redirect.test.ts"
-/** @type {any} */ (mockLogger)
+mockLogger as unknown as LoggerTôi thực sự không biết cách astruyền hai lần trong JSDoc - và bây giờ tôi không cần.
Phần kết luận
Giờ đây, chúng tôi có một cơ sở mã TypeScript Azure Function, với tất cả khả năng gỡ lỗi/thử nghiệm/triển khai mà chúng tôi đã có trước đây. Chúng tôi không phải làm bất cứ điều gì xung quanh việc triển khai, bởi vì nó chỉ hoạt động™️. Tôi hy vọng bài viết này đã được hữu ích cho bạn!
Nguồn bài viết: https://dev.to
1683794950
在 Azure 中集成 ChatGPT 的 8 个简单步骤
在此 Azure 教程中，我们将了解在 Azure 中集成 ChatGPT 的 8 个简单步骤。虚拟助手和聊天机器人在过去几年中越来越受欢迎，这是有充分理由的。许多程序的自动化为企业提供了一种与客户沟通的快速直接的方式。OpenAI 的 ChatGPT 是一种有效的语言模型，可用于构建聊天机器人和虚拟助手。在本文中，我们将带您完成将 ChatGPT 集成到 Microsoft 的云计算平台 Azure 中的过程。
1. 创建一个 Azure 帐户
创建 Azure 帐户是将 ChatGPT 与 Azure 集成的第一步。如果您已有 Azure 帐户，请跳过此步骤。否则，请访问 Azure 网站并选择“免费开始”选项。要创建您的帐户，请遵守说明。
2. 创建一个新的 Azure 机器人服务
以下步骤是在设置您的 Azure 帐户后创建一个新的 Azure Bot 服务。登录到您的 Azure 帐户并转到 Azure 门户以完成此操作。单击“创建资源”后，从选项列表中选择“AI + 机器学习”是一个不错的选择。选择“Bot Channels Registration”，然后单击“Create”。
3. 配置您的机器人服务
您必须在创建新的 Bot Service 后对其进行配置。为此，请在 Azure 门户中单击您的机器人服务，转到“设置”选项卡。必须在此处输入您的 Bot 的名称、描述和其他基本信息。
4. 将 ChatGPT API 添加到您的机器人服务
然后，下一步必须将 ChatGPT API 添加到您的机器人服务中。为此，请转到您的机器人服务的“频道”选项卡并选择“添加频道”按钮。从可用渠道列表中选择“网络聊天”，然后按照屏幕上的说明将其添加到您的机器人服务中。
5. 训练您的 ChatGPT 模型
您必须先训练您的模型，然后才能开始在您的机器人中使用 ChatGPT。您必须为 ChatGPT 提供示例对话的数据集才能完成此操作。您可以制作数据集或使用已经存在的数据集。获得数据集后，您可以使用 OpenAI API 训练 ChatGPT 模型。
6. 将 ChatGPT 集成到您的机器人中
一旦训练完成，您就可以将 ChatGPT 模型合并到您的机器人服务中。为此，您必须使用适用于 Node.js 的 Bot Builder SDK 开发全新的机器人应用程序。Azure 文档包含有关如何执行此操作的说明。开发机器人应用程序后，您可以使用 OpenAI API 将 ChatGPT 模型集成到其中。
7. 评估你的机器人
在将 ChatGPT 集成到您的 Bot 之后，是时候测试它了。使用您在第 4 步中添加的网络聊天频道，您可以完成此操作。只需单击机器人服务中的“在网络聊天中测试”按钮即可开始与您的机器人聊天。
八、结论
在 Azure 中集成 ChatGPT 可能具有挑战性，但如果您遵循这些详细说明，您的 Bot 应该会立即运行。在将您的 ChatGPT 模型投入生产之前，不要忘记对其进行全面训练和彻底测试。福！
文章来源： https: //www.c-sharpcorner.com
1683793380
How to Migrate Azure Functions from JSDoc JavaScript to TypeScript
In this TypeScript - JavaScript tutorial we will learn about How to Migrate Azure Functions from JSDoc JavaScript to TypeScript. I implemented this using JSDoc JavaScript. I've since migrated this to TypeScript and I thought it would be interesting to share the process.
Why migrate from JSDoc JavaScript to TypeScript?
As regular readers will know, I'm both a big fan of TypeScript and a big fan of JSDoc JavaScript. I think both are great. So why migrate from JSDoc JavaScript to TypeScript? For me it's mostly about the developer experience; JSDoc is more verbose, and the wider ecosystem does a lot more TypeScript than it does JSDoc JavaScript. So when you get beyond a simple application, for me at least, TypeScript is a better choice.
My blog is an Azure Static Web App with an Azure Functions back end. I've been using JSDoc JavaScript for my Azure Functions. This post will take the back end and migrate it to TypeScript. There's various affordances that I have in place already that I don't want to lose along the way:
- I can debug in VS Code
- I deploy using GitHub Actions
- I have automated tests in place using Jest
All of these affordances are available to me with TypeScript, and I want to keep them. Let's begin migrating. Incidentally, the code for this migration lies in this PR.
Migrating the tsconfig.json
Our tsconfig.json manages the way the TypeScript compiler interacts with our code. We'll start by migrating this:
``````diff title="tsconfig.json"
{
"compilerOptions": {
- "noEmit": true,
- "noEmit": false,
- "outDir": "dist",
- "rootDir": ".",
"sourceMap": true,
"allowJs": false,
"checkJs": false,
"moduleResolution": "node",
}
}
Let's look at the changes we've made:
- We're now emitting files from our compilation thanks to
noEmitbeing set tofalse. We will no longer be actually running the code we write, but we will run the JavaScript we emit. - We're specifying an
outDirofdist- this is where our compiled JavaScript will be emitted. - We're specifying a
rootDirof.- this is the root of our TypeScript source files. - We're creating source maps for our emitted JavaScript files - this will help us debug our original source code. (Even though we're not running it.)
- We're no longer allowing JavaScript files to be part of our program thanks to
allowJsbeing set tofalse. (And we're not checking them either thanks tocheckJsbeing set tofalse- I suspect this is implicitly set tofalsetoallowJsbeingfalse- just to be clear I've specified it.) - We're specifying a
moduleResolutionofnode- this is how TypeScript will look up a file from a given module specifier.
Migrating the package.json
To migrate our package.json we'll need to add some dependencies and tweak our scripts:
```diff title="package.json"
"scripts": {
"build": "tsc",
- "watch": "tsc -w",
- "prestart": "npm run build", "start": "func start", "test": "jest" }, "devDependencies": { "@azure/functions": "^3.5.0",
- "@types/jest": "^29.2.5",
- "@types/node": "^18.x", "jest": "^29.3.1",
- "ts-jest": "^29.1.0", "typescript": "^5.0.0" } } ```
We're adding two scripts:
watch- this will watch our TypeScript files and recompile them when they change - we don't need this really; but it can be useful depending on your preferred workflow.prestart- this will run beforestartand will ensure our TypeScript files are compiled, and we have up to date JavaScript to run.
In our devDependencies we're adding dependencies for Jest and Node.js. We're also adding ts-jest which will allow us to run Jest tests written in TypeScript.
Migrating .vscode/settings.json and .vscode/tasks.json
I mentioned debugging earlier - to get that in place we need to work on the settings.json and tasks.json files in the .vscode folder. First the settings.json:
```diff title="settings.json"
- "azureFunctions.projectLanguage": "JavaScript",
- "azureFunctions.projectLanguage": "TypeScript", ```
The above is pretty self explanatory. We're changing the language of our Azure Functions project from JavaScript to TypeScript. Now the tasks.json:
```diff title="tasks.json"
{
"version": "2.0.0",
"tasks": [
- {
- "type": "shell",
- "label": "npm build (functions)",
- "command": "npm run build",
- "dependsOn": "npm install (functions)",
- "problemMatcher": "$tsc",
- "options": {
- "cwd": "${workspaceFolder}/blog-website/api"
- }
- }, ] } ```
We've got a new task in place here that runs our npm run build script. This will compile our TypeScript files to JavaScript. We've also got a cwd set to blog-website/api - this is the folder where our Azure Functions live - your own will likely be different. Alongside this new script, there's some tweaks to existing tasks to make them depend on our new build task:
```diff title="tasks.json"
{
"version": "2.0.0",
"tasks": [
{
"type": "func",
"label": "func: host start",
"command": "host start",
"problemMatcher": "$func-node-watch",
"isBackground": true,
- "dependsOn": "npm build (functions)",
- "options": {
- "cwd": "${workspaceFolder}/blog-website/api"
- } }, // ... { "type": "shell", "label": "npm prune (functions)", "command": "npm prune --production",
- "dependsOn": "npm build (functions)", "problemMatcher": [], "options": { "cwd": "${workspaceFolder}/blog-website/api" } } ] } ```
Migrate our Azure Functions
This isn't going to be an exhaustive guide of migrating from JSDoc JavaScript to TypeScript. I'm going to focus on the things that I found most relevant to Azure Functions. Let's start with the fallback/function.json file that powers our dynamic redirects and lives at /api/fallback:
```diff title="fallback/function.json"
{
"bindings": [
{
"authLevel": "anonymous",
"type": "httpTrigger",
"direction": "in",
"name": "req",
"methods": ["get", "post"]
},
{
"type": "http",
"direction": "out",
"name": "res"
}
],
- "scriptFile": "../dist/fallback/index.js" } ```
There's one addition here, to repoint the scriptFile to the compiled JavaScript.
Now let's look at the code for the function. Originally a JavaScript file named index.js; it must be renamed to index.ts. The original code looked like this:
```js title="fallback/index.js"
const redirect = require('./redirect');
const saveToDatabase = require('./saveToDatabase');
/**
*
- @param { import("@azure/functions").Context } context
- @param { import("@azure/functions").HttpRequest } req */ async function fallback(context, req) { //... }
module.exports = fallback;
After renaming to `index.ts` and adding some TypeScript types, it looks like this:
```ts title="fallback/index.ts"
import type { AzureFunction, Context, HttpRequest } from '@azure/functions';
import { redirect } from './redirect';
import { saveToDatabase } from './saveToDatabase';
const httpTrigger: AzureFunction = async function (
context: Context,
req: HttpRequest
): Promise<void> {
//...
};
export default httpTrigger;As we can see, the type importing becomes much more succinct. We're also exporting the function as default rather than module.exports. This is because we're using ES Modules rather than CommonJS modules for authoring. We can also see that we're using import rather than require to import our functions. Whilst CommonJS was more straightforward to use, the syntax for ES Modules feels much nicer to use; at least to me. (It's worth noting that we're not using ES Modules in our compiled JavaScript - we're still using CommonJS there; but we don't need to think about that when we're writing our code.)
I won't walk through migrating the other files, but the process is the same. Rename the file to .ts, add TypeScript types, and use import rather than require.
Migrating our tests
We're pretty much on the home stretch now; we just need to migrate our tests. Let's start with the jest.config.js:
```diff title="jest.config.js"
- preset: 'ts-jest',
- testPathIgnorePatterns: ['/node_modules/', '/dist/'], ```
We're adding a preset of ts-jest which will allow us to run TypeScript tests. If you recall we added the ts-jest dependency earlier; it was for this.
We're also adding dist to our testPathIgnorePatterns - this is because we don't want to run our tests against our compiled JavaScript - we'd end up running the tests twice without this.
Let's turn our attention to the tests directly. Again we do the classic rename from .js to .ts, and our imports become terser and more ES Module-y:
```diff title="redirect.test.ts"
-/**
- * @typedef { import("@azure/functions").Logger } Logger
- */ +import type { Logger } from '@azure/functions'; -const { describe, expect, test } = require('@jest/globals'); +import { describe, expect, test } from '@jest/globals'; -const redirect = require('./redirect'); +import { redirect } from './redirect'; ```
Beautiful. Finally we've got some tweaks to the code of the tests themselves. Firstly, declaring our mock becomes much easier:
```diff title="redirect.test.ts"
-/** @type {jest.Mock} */ const mockLogger = jest.fn();
+const mockLogger: jest.Mock = jest.fn();
Secondly, casting our mock to the type we want is much more straightforward:
```diff title="redirect.test.ts"
-/** @type {any} */ (mockLogger)
+mockLogger as unknown as LoggerI have no real how to as cast twice in JSDoc - and now I don't need to.
Conclusion
We now have a TypeScript Azure Functions codebase, with all of the debugging / testing / deployment affordances we had before. We didn't have to do anything around deployment, because it just works™️. I hope this post has been useful to you!
Article source: https://dev.to
1683785340
Chọn một dịch vụ lưu trữ Azure
Trong hướng dẫn Azure này, chúng ta sẽ tìm hiểu về Cách chọn Dịch vụ lưu trữ Azure phù hợp?. Azure Storage là giải pháp lưu trữ dựa trên đám mây của Microsoft. Nó vượt ra ngoài lưu trữ tệp truyền thống, cung cấp một loạt các dịch vụ lưu trữ hiện đại. Bài viết này sẽ khám phá các dịch vụ khác nhau có sẵn và các trường hợp sử dụng cụ thể của chúng, cho phép bạn chọn dịch vụ phù hợp nhất với nhu cầu của mình.
Azure Blob Storage: Lưu trữ dữ liệu phi cấu trúc một cách dễ dàng
Azure Blob Storage là một dịch vụ lưu trữ mạnh mẽ và có thể mở rộng được thiết kế đặc biệt để lưu trữ dữ liệu phi cấu trúc. Cho dù đó là hình ảnh, video, tài liệu, bản sao lưu, nhật ký hay bất kỳ loại tệp nào khác, Blob Storage cung cấp giải pháp hiệu quả về chi phí và đáng tin cậy để quản lý lượng dữ liệu khổng lồ trên đám mây.
Các trường hợp sử dụng Azure Blob Storage
- Phân phối nội dung và phương tiện: Lưu trữ và phân phối hiệu quả các tệp hình ảnh, video và âm thanh cho các mạng phân phối nội dung (CDN) và các nền tảng truyền phát phương tiện.
- Sao lưu và khôi phục sau thảm họa: Lưu trữ và truy cập các bản sao lưu một cách an toàn, đảm bảo bảo vệ dữ liệu và cho phép khôi phục sau thảm họa dễ dàng.
- Lưu trữ dữ liệu: Tuân thủ các yêu cầu quy định bằng cách lưu trữ dữ liệu hiệu quả về mặt chi phí cho các mục đích lịch sử và lưu giữ lâu dài.
- Lưu trữ dữ liệu nhật ký và IoT: Xử lý quá trình nhập và lưu trữ dữ liệu nhật ký và đo từ xa IoT để phân tích lịch sử và phân tích theo thời gian thực.
- Lưu trữ ứng dụng phân tán: Đóng vai trò là kho lưu trữ trung tâm cho dữ liệu được chia sẻ trên các ứng dụng phân tán, tạo điều kiện trao đổi và cộng tác dữ liệu hiệu quả.
- Di chuyển dữ liệu và Nhập/Xuất: Đơn giản hóa việc di chuyển dữ liệu sang đám mây và truyền khối lượng lớn dữ liệu thông qua vận chuyển vật lý bằng dịch vụ Nhập/Xuất.
Tệp Azure: Chia sẻ tệp hiệu suất cao trên đám mây
Tệp Azure được sử dụng để thiết lập hệ thống tệp được chia sẻ giữa các máy ảo. Chia sẻ tệp qua mạng cho phép bạn tập trung lưu trữ tệp, cung cấp một vị trí duy nhất nơi nhiều người dùng hoặc hệ thống có thể truy cập và cộng tác trên các tệp. Điều này hợp lý hóa việc quản lý tệp và loại bỏ nhu cầu sao chép tệp riêng lẻ hoặc các vị trí lưu trữ rải rác.
Sự khác biệt giữa Lưu trữ Azure Blob và Tệp Azure
Blob Storage được thiết kế để lưu trữ dữ liệu phi cấu trúc, chẳng hạn như hình ảnh và video, đồng thời được truy cập thông qua API REST. Mặt khác, Azure Files cung cấp khả năng lưu trữ ở cấp độ tệp, hỗ trợ các giao thức SMB và NFS để chia sẻ quyền truy cập vào dữ liệu có cấu trúc, làm cho nó phù hợp với các kịch bản hệ thống tệp truyền thống và tích hợp dễ dàng với các ứng dụng hiện có.
Bảng Azure: Lưu trữ khóa-giá trị NoSQL cho các ứng dụng có thể mở rộng
Azure Tables là dịch vụ lưu trữ khóa-giá trị NoSQL. Nó được thiết kế để xử lý một lượng lớn dữ liệu có cấu trúc theo cách có khả năng mở rộng và hiệu quả cao. Nó cung cấp một lược đồ linh hoạt, thời gian truy cập nhanh và tự động thay đổi quy mô, làm cho nó trở nên lý tưởng để xây dựng các ứng dụng yêu cầu lưu trữ dữ liệu nhanh và có thể mở rộng. Để biết thêm thông tin về cách bắt đầu với Azure Table Storage, hãy đọc Bắt đầu với Azure Table Storage
Trường hợp sử dụng
- Ứng dụng web và lưu trữ dữ liệu người dùng.
- Nhập và phân tích dữ liệu IoT.
- Ghi nhật ký và quản lý đường mòn kiểm toán.
- Hệ thống quản lý nội dung (CMS) và lưu trữ nội dung có cấu trúc.
- Lưu trữ và lập chỉ mục siêu dữ liệu.
Hàng đợi Azure: Nhắn tin đáng tin cậy cho các ứng dụng có thể mở rộng
Hàng đợi Azure là dịch vụ nhắn tin cung cấp giao tiếp không đồng bộ và đáng tin cậy giữa các thành phần của ứng dụng phân tán. Nó cung cấp một giải pháp đơn giản và có thể mở rộng để tách các dịch vụ, đảm bảo gửi tin nhắn đáng tin cậy và cho phép xử lý khối lượng công việc hiệu quả. Nó không hỗ trợ các chủ đề, bạn phải truy cập Azure Service Bus.
Dưới đây là một số trường hợp sử dụng mà hàng đợi giúp bạn:
- Giảm tải tác vụ và hàng đợi công việc để xử lý không đồng bộ.
- Kiến trúc và thông báo hướng sự kiện.
- Giao tiếp liên thành phần đáng tin cậy trong các ứng dụng phân tán.
- Ưu tiên xử lý cho các nhiệm vụ khẩn cấp hoặc quan trọng.
- Bộ đệm và cân bằng tải để xử lý khối lượng công việc tăng đột biến.
- Phối hợp và điều phối quy trình làm việc.
Nguồn bài viết: https://www.c-sharpcorner.com
1683772277
8 простых шагов для интеграции ChatGPT в Azure
В этом руководстве по Azure мы узнаем о 8 простых шагах по интеграции ChatGPT в Azure. За последние несколько лет популярность виртуальных помощников и чат-ботов возросла, и на то есть веские причины. Автоматизация многих процедур дает предприятиям быстрый и простой способ общения со своими клиентами. ChatGPT от OpenAI — это эффективная языковая модель, которую можно использовать для создания чат-ботов и виртуальных помощников. В этой статье мы познакомим вас с процессом интеграции ChatGPT в платформу облачных вычислений Microsoft Azure.
1. Создайте учетную запись Azure
Создание учетной записи Azure — это первый шаг в интеграции ChatGPT с Azure. Пропустите этот шаг, если у вас уже есть учетная запись Azure. В противном случае посетите веб-сайт Azure и выберите вариант «Начать бесплатно». Чтобы создать учетную запись, следуйте инструкциям.
2. Создайте новую службу Azure Bot.
Следующий шаг — создать новую службу Azure Bot после настройки учетной записи Azure. Войдите в свою учетную запись Azure и перейдите на портал Azure, чтобы сделать это. Выбор «ИИ + машинное обучение» из списка вариантов после нажатия «Создать ресурс» — хороший выбор. Выберите «Регистрация бот-каналов» и нажмите «Создать».
3. Настройте службу ботов
Вы должны настроить новую службу Bot после ее создания. Для этого перейдите на вкладку «Настройки», щелкнув свой бот-сервис на портале Azure. Здесь необходимо ввести имя вашего бота, описание и другую основную информацию.
4. Добавьте ChatGPT API в свой бот-сервис.
Затем API ChatGPT необходимо добавить в службу Bot в качестве следующего шага. Для этого перейдите на вкладку «Каналы» вашего бота-сервиса и нажмите кнопку «Добавить канал». Выберите «Веб-чат» из списка доступных каналов, затем следуйте инструкциям на экране, чтобы добавить его в службу ботов.
5. Обучите свою модель ChatGPT
Вы должны обучить свою модель, прежде чем сможете начать использовать ChatGPT в своем боте. Для этого вы должны предоставить ChatGPT набор данных с образцами разговоров. Вы можете либо создать свой набор данных, либо использовать уже существующий. Получив набор данных, вы можете обучить свою модель ChatGPT с помощью API OpenAI.
6. Интегрируйте ChatGPT в своего бота
Вы можете включить свою модель ChatGPT в службу Bot после ее обучения. Вы должны сделать это, разработав новое приложение бота с помощью пакета SDK Bot Builder для Node.js. Документация Azure содержит инструкции о том, как это сделать. После разработки приложения для бота вы можете использовать API OpenAI для интеграции в него модели ChatGPT.
7. Оцените своего бота
Пришло время протестировать ChatGPT после того, как вы интегрировали его в своего бота. Это можно сделать с помощью канала веб-чата, добавленного на шаге 4. Просто начните чат со своим ботом, нажав кнопку «Проверить в веб-чате» в службе бота.
8. Заключение
Интеграция ChatGPT в Azure может оказаться сложной задачей, но если вы будете следовать этим подробным инструкциям, ваш бот заработает в кратчайшие сроки. Прежде чем запускать модель ChatGPT в производство, не забудьте полностью ее обучить и тщательно протестировать. Везение!
Источник статьи: https://www.c-sharpcorner.com
