Yandex cloud

Привет, Хабр!

В этой статье мы создадим готовый шаблон-монолит, который можно брать за основу нового fullstack приложения как скелет для навешивания функционала.

Эта статья будет полезна, если вы:

• Начинающий fullstack-разработчик;
• Стартапер, который пишет MVP чтобы проверить гипотезу.

Почему выбрал такой стек:

• Angular: имею много опыта в нем, люблю строгую архитектуру и Typescript из коробки, выходец из .NET
• NestJS: тот-же язык, та-же архитектура, быстрое написание REST API, возможность в дальнейшем пересесть на Serverless (дешевле виртуалки)
• PostgreSQL: Собираюсь хоститься в Яндекс.Облаке, на минималках дешевле на 30% чем MongoDB

Прежде чем написать статью, поискал на хабре статьи про подобный кейс, нашел следующее:

• Angular и SEO: как их подружить?
• Firebase + Angular Universal = невозможное возможно
• Дружим Angular с Google (Angular Universal)
• Удивительный Angular

Из этого ничего не описывает "скопировал и вставил" или дает ссылки на то что еще нужно дорабатывать.

Оглавление:

1. Создаем Angular приложение и добавляем библиотеку компонентов ng-zorro
2. Устанавливаем NestJS и решаем проблемы с SSR
3. Делаем API на NestJS и подключаем к фронту
4. Подключаем базу данных PostgreSQL

1. Создаем Angular приложение

Установим Angular-CLI чтобы создавать SPA-сайты на Ангуляре:

npm install -g @angular/cli

Создадим Angular приложение с помощью следующей команды:

ng new angular-habr-nestjs

Далее переходим в папку приложения и запускаем, чтобы проверить работоспособность:

cd angular-habr-nestjsng serve --open

Приложение создалось. Подключаем библиотеку NG-Zorro:

ng add ng-zorro-antd

Далее выбираем следующие конфигурации библиотеки:

? Enable icon dynamic loading [ Detail: https://ng.ant.design/components/icon/en ] Yes? Set up custom theme file [ Detail: https://ng.ant.design/docs/customize-theme/en ] No? Choose your locale code: ru_RU? Choose template to create project: sidemenu

Эта конфигурация заменит содержимое app.component на дизайн с менюшкой слева, футером и хедером и подключит локализацию на русском языке:

В данной статье мы отобразим список данных для наглядности, поэтому добавим простенькую табличку в компоненте src/app/pages/welcome, который сгенерил NG-Zorro:
Пример взят отсюда:
https://ng.ant.design/components/table/en

// welcome.component.html<nz-table #basicTable [nzData]="items$ | async"> <thead> <tr>  <th>Name</th>  <th>Age</th>  <th>Address</th> </tr> </thead> <tbody> <tr *ngFor="let data of basicTable.data">  <td>{{ data.name }}</td>  <td>{{ data.age }}</td>  <td>{{ data.address }}</td> </tr> </tbody></nz-table>

// welcome.module.tsimport { NgModule } from '@angular/core';import { WelcomeRoutingModule } from './welcome-routing.module';import { WelcomeComponent } from './welcome.component';import { NzTableModule } from 'ng-zorro-antd';import { CommonModule } from '@angular/common';@NgModule({ imports: [  WelcomeRoutingModule,  NzTableModule, // Добавили для таблицы  CommonModule // Добавили для пайпа async ], declarations: [WelcomeComponent], exports: [WelcomeComponent]})export class WelcomeModule {}

// welcome.component.tsimport { Component, OnInit } from '@angular/core';import { Observable, of } from 'rxjs';import { HttpClient } from '@angular/common/http';import { share } from 'rxjs/operators';@Component({ selector: 'app-welcome', templateUrl: './welcome.component.html', styleUrls: ['./welcome.component.scss']})export class WelcomeComponent implements OnInit { items$: Observable<Item[]> = of([  {name: 'Вася', age: 24, address: 'Москва'},  {name: 'Петя', age: 23, address: 'Лондон'},  {name: 'Миша', age: 21, address: 'Париж'},  {name: 'Вова', age: 23, address: 'Сидней'} ]); constructor(private http: HttpClient) { } ngOnInit() { } // Сразу напишем метод к бэку, понадобится позже getItems(): Observable<Item[]> {  return this.http.get<Item[]>('/api/items').pipe(share()); }}interface Item { name: string; age: number; address: string;}

Получилось следующее:

2. Устанавливаем NestJS

Далее установим NestJS таким образом, чтобы он предоставил Angular Universal (Server Side Rendering) из коробки и напишем пару ендпоинтов.

ng add @nestjs/ng-universal

После установки, запускаем наш SSR с помощью команды:

npm run serve

И вот уже первый косяк :) У нас появляется следующая ошибка:

TypeError: Cannot read property 'indexOf' of undefined  at D:\Projects\angular-habr-nestjs\node_modules\@nestjs\ng-universal\dist\utils\setup-universal.utils.js:35:43  at D:\Projects\angular-habr-nestjs\dist\server\main.js:107572:13  at View.engine (D:\Projects\angular-habr-nestjs\node_modules\@nestjs\ng-universal\dist\utils\setup-universal.utils.js:30:11)  at View.render (D:\Projects\angular-habr-nestjs\node_modules\express\lib\view.js:135:8)  at tryRender (D:\Projects\angular-habr-nestjs\node_modules\express\lib\application.js:640:10)  at Function.render (D:\Projects\angular-habr-nestjs\node_modules\express\lib\application.js:592:3)  at ServerResponse.render (D:\Projects\angular-habr-nestjs\node_modules\express\lib\response.js:1012:7)  at D:\Projects\angular-habr-nestjs\node_modules\@nestjs\ng-universal\dist\angular-universal.module.js:60:66  at Layer.handle [as handle_request] (D:\Projects\angular-habr-nestjs\node_modules\express\lib\router\layer.js:95:5)  at next (D:\Projects\angular-habr-nestjs\node_modules\express\lib\router\route.js:137:13)

Чтобы решить косяк, зайдем в файл server/app.module.ts и поменяем значение liveReload на false:

import { Module } from '@nestjs/common';import { AngularUniversalModule } from '@nestjs/ng-universal';import { join } from 'path';@Module({ imports: [  AngularUniversalModule.forRoot({   viewsPath: join(process.cwd(), 'dist/browser'),   bundle: require('../server/main'),   liveReload: false  }) ]})export class ApplicationModule {}

Также подтюним конфиг тайпскрипта, так-как эта конфигурация не взлетает с использованием Ivy рендера:

// tsconfig.server.json{ "extends": "./tsconfig.app.json", "compilerOptions": {  "outDir": "./out-tsc/server",  "target": "es2016",  "types": [   "node"  ] }, "files": [  "src/main.server.ts" ], "angularCompilerOptions": {  "enableIvy": false, // Добавили флажок  "entryModule": "./src/app/app.server.module#AppServerModule" }}

После пересоберем приложение командой ng run serve чтобы SSR заработал.

Ура! SSR подрубился, но как видимо в devtools он приходит с кривыми стилями.

Добавим extractCss: true, который позволит выносить стили не в styles.js, а в styles.css:

// angular.json..."architect": {    "build": {     "builder": "@angular-devkit/build-angular:browser",     "options": {      "outputPath": "dist/browser",      "index": "src/index.html",      "main": "src/main.ts",      "polyfills": "src/polyfills.ts",      "tsConfig": "tsconfig.app.json",      "aot": true,      "assets": [       "src/favicon.ico",       "src/assets",       {        "glob": "**/*",        "input": "./node_modules/@ant-design/icons-angular/src/inline-svg/",        "output": "/assets/"       }      ],      "extractCss": true, // Добавили флажок      "styles": [       "./node_modules/ng-zorro-antd/ng-zorro-antd.min.css",       "src/styles.scss"      ],      "scripts": []     },...

Также подключим стили библиотеки в app.component.scss:

// app.component.scss@import "~ng-zorro-antd/ng-zorro-antd.min.css"; // Подключили стили:host { display: flex; text-rendering: optimizeLegibility; -webkit-font-smoothing: antialiased; -moz-osx-font-smoothing: grayscale;}.app-layout { height: 100vh;}...

Теперь стили подключены, SSR отдает страничку со стилями, но мы видим что сначала у нас грузится SSR, потом страница моргает и отрисовывается CSR (Client Side Rendering). Это решается следующим способом:

import { NgModule } from '@angular/core';import { Routes, RouterModule } from '@angular/router';const routes: Routes = [ { path: '', pathMatch: 'full', redirectTo: '/welcome' }, { path: 'welcome', loadChildren: () => import('./pages/welcome/welcome.module').then(m => m.WelcomeModule) }];@NgModule({ imports: [RouterModule.forRoot(routes, {initialNavigation: 'enabled', scrollPositionRestoration: 'enabled'})], // Добавили initialNavigation, scrollPositionRestoration exports: [RouterModule]})export class AppRoutingModule { }

• initialNavigation: 'enabled' дает инструкцию роутингу не отрисовывать страницу, если уже загружена через SSR
• scrollPositionRestoration: 'enabled' скролит страницу наверх при каждом роутинге.

3. Сделаем пару ендпоинтов на NestJS

Перейдем в папку server и создадим первый контроллер items:

cd servernest g module itemsnest g controller items --no-spec

// items.module.tsimport { Module } from '@nestjs/common';import { ItemsController } from './items.controller';@Module({ controllers: [ItemsController]})export class ItemsModule {}

// items.controller.tsimport { Controller } from '@nestjs/common';@Controller('items')export class ItemsController {}

Контроллер и модуль создались. Создадим метод на получение списка items и на добавление объекта в список:

// server/src/items/items.controller.tsimport { Body, Controller, Get, Post } from '@nestjs/common';class Item { name: string; age: number; address: string;}@Controller('items')export class ItemsController { // для простоты данные взял из Angular private items: Item[] = [  {name: 'Вася', age: 24, address: 'Москва'},  {name: 'Петя', age: 23, address: 'Лондон'},  {name: 'Миша', age: 21, address: 'Париж'},  {name: 'Вова', age: 23, address: 'Сидней'} ]; @Get() getAll(): Item[] {  return this.items; } @Post() create(@Body() newItem: Item): void {  this.items.push(newItem); }}

Попробуем вызвать GET в Postman:

Отлично, работает! Обратите внимание, вызываем метод GET items с префиксом api, который ставится автоматически в файле server/main.ts при установке NestJS:

// server/main.tsimport { NestFactory } from '@nestjs/core';import { ApplicationModule } from './app.module';async function bootstrap() { const app = await NestFactory.create(ApplicationModule); app.setGlobalPrefix('api'); // Это префикс await app.listen(4200);}bootstrap();

Теперь прикрутим бэк к фронту. Возвращаемся к файлу welcome.component.ts и делаем запрос списка к бэку:

// welcome.component.tsimport { Component, OnInit } from '@angular/core';import { Observable, of } from 'rxjs';import { HttpClient } from '@angular/common/http';import { share } from 'rxjs/operators';@Component({ selector: 'app-welcome', templateUrl: './welcome.component.html', styleUrls: ['./welcome.component.scss']})export class WelcomeComponent implements OnInit { items$: Observable<Item[]> = this.getItems(); // прикрутили вызов бэка constructor(private http: HttpClient) { } ngOnInit() { } getItems(): Observable<Item[]> {  return this.http.get<Item[]>('/api/items').pipe(share()); }}interface Item { name: string; age: number; address: string;}

Можно увидеть что апиха на фронте дергается, но также дергается и в SSR, причем с ошибкой:

Ошибка при запросе в SSR решается следующим способом:

// welcome.component.tsimport { Component, OnInit } from '@angular/core';import { Observable, of } from 'rxjs';import { HttpClient } from '@angular/common/http';import { share } from 'rxjs/operators';@Component({ selector: 'app-welcome', templateUrl: './welcome.component.html', styleUrls: ['./welcome.component.scss']})export class WelcomeComponent implements OnInit { items$: Observable<Item[]> = this.getItems(); // прикрутили вызов бэка constructor(private http: HttpClient) { } ngOnInit() { } getItems(): Observable<Item[]> {  return this.http.get<Item[]>('http://localhost:4200/api/items').pipe(share()); // Прописали полный путь к апихе чтобы SSR не ругался }}interface Item { name: string; age: number; address: string;}

Чтобы исключить двойной запрос к апихе (один на SSR, другой на фронте), нужно проделать следующее:

• Установим библиотеку @nguniversal/common:

npm i @nguniversal/common

• В файле app/app.module.ts добавим модуль для запросов из SSR:

// app.module.tsimport { BrowserModule } from '@angular/platform-browser';import { NgModule } from '@angular/core';import { AppRoutingModule } from './app-routing.module';import { AppComponent } from './app.component';import { IconsProviderModule } from './icons-provider.module';import { NzLayoutModule } from 'ng-zorro-antd/layout';import { NzMenuModule } from 'ng-zorro-antd/menu';import { FormsModule } from '@angular/forms';import { HttpClientModule } from '@angular/common/http';import { BrowserAnimationsModule } from '@angular/platform-browser/animations';import { NZ_I18N } from 'ng-zorro-antd/i18n';import { ru_RU } from 'ng-zorro-antd/i18n';import { registerLocaleData } from '@angular/common';import ru from '@angular/common/locales/ru';import {TransferHttpCacheModule} from '@nguniversal/common';registerLocaleData(ru);@NgModule({ declarations: [  AppComponent ], imports: [  BrowserModule.withServerTransition({ appId: 'serverApp' }),  TransferHttpCacheModule, // Добавили  AppRoutingModule,  IconsProviderModule,  NzLayoutModule,  NzMenuModule,  FormsModule,  HttpClientModule,  BrowserAnimationsModule ], providers: [{ provide: NZ_I18N, useValue: ru_RU }], bootstrap: [AppComponent]})export class AppModule { }

Схожую операцию проделаем с app.server.module.ts:

// app.server.module.tsimport { NgModule } from '@angular/core';import { ServerModule, ServerTransferStateModule } from '@angular/platform-server';import { AppModule } from './app.module';import { AppComponent } from './app.component';@NgModule({ imports: [  AppModule,  ServerModule,  ServerTransferStateModule, // Добавили ], bootstrap: [AppComponent],})export class AppServerModule {}

Хорошо. Теперь получаем данные из апи в SSR, отрисовываем на форме, отдаем на фронт и тот не делает повторных запросов.

4. Подключим базу PostgreSQL

Подключим библиотеки для работы с PostgreSQL, также будем использовать TypeORM для работы с базой:

npm i pg typeorm @nestjs/typeorm

Внимание: у вас уже должна быть установлена PostgreSQL с базой внутри.

Описываем конфиг подключения к базе в server/app.module.ts:

// server/app.module.tsimport { Module } from '@nestjs/common';import { AngularUniversalModule } from '@nestjs/ng-universal';import { join } from 'path';import { ItemsController } from './src/items/items.controller';import { TypeOrmModule } from '@nestjs/typeorm';@Module({ imports: [  AngularUniversalModule.forRoot({   viewsPath: join(process.cwd(), 'dist/browser'),   bundle: require('../server/main'),   liveReload: false  }),  TypeOrmModule.forRoot({ // Конфиг подключения к базе   type: 'postgres',   host: 'localhost',   port: 5432,   username: 'postgres',   password: 'admin',   database: 'postgres',   entities: ['dist/**/*.entity{.ts,.js}'],   synchronize: true  }) ], controllers: [ItemsController]})export class ApplicationModule {}

Немного про поля конфига:

• type: указываем название типа базы данных, к которой подключаемся
• host и port: место где база хостится
• username и password: аккаунт для этой базы
• database: название базы
• entities: путь, откуда будем брать сущности для схемы нашей базы

По последнему пункту, нужно создать сущность Item для мапинга полей в базу:

// server/src/items/item.entity.tsimport { Column, CreateDateColumn, Entity, PrimaryGeneratedColumn } from 'typeorm/index';@Entity()export class ItemEntity { @PrimaryGeneratedColumn() id: number; @CreateDateColumn() createDate: string; @Column() name: string; @Column() age: number; @Column() address: string;}

Далее свяжем эту сущность с нашей базой.

// items.module.tsimport { Module } from '@nestjs/common';import { TypeOrmModule } from '@nestjs/typeorm';import { ItemEntity } from './item.entity';import { ItemsController } from './items.controller';@Module({ imports: [  TypeOrmModule.forFeature([ItemEntity]) // Подключаем фича-модуль и указываем сущности базы ], controllers: [ItemsController]})export class ItemsModule {}

Теперь укажем в контроллере, что хотим работать с базой, а не кешем:

// items.controller.tsimport { Body, Controller, Get, Post } from '@nestjs/common';import { ItemEntity } from './item.entity';import { InjectRepository } from '@nestjs/typeorm';import { Repository } from 'typeorm/index';interface Item { name: string; age: number; address: string;}@Controller('items')export class ItemsController { constructor(@InjectRepository(ItemEntity)       private readonly itemsRepository: Repository<ItemEntity>) { // Подключили репозиторий } @Get() getAll(): Promise<Item[]> {  return this.itemsRepository.find(); } @Post() create(@Body() newItem: Item): Promise<Item> {  const item = this.itemsRepository.create(newItem);  return this.itemsRepository.save(item); }}

Проверим работу апихи в Postman:

Работает. Потыкали несколько раз постман, посмотрим что записалось в базе с помощью DBeaver:

Отлично! В базе есть, посмотрим как выглядит на фронте:

Готово! Мы сделали fullstack приложение, с которым можно работать дальше.

P.S. Сразу поясню следующее:

• Вместо Ng-Zorro вы можете использовать любую другую библиотеку, например Angular Material. Мне она лично не зашла из-за сложности разработки;
• Я знаю, что нужно на бэке использовать сервисы, а не напрямую дергать базу в контроллерах. Эта статья о том, как решив проблемы "влоб" получить MVP с которым можно работать, а не про архитектуру и паттерны;
• Вместо вписывания на фронте http://localhost:4200/api возможно лучше написать интерсептор и проверять откуда мы стучимся

Полезные ссылки:

• Библиотека компонентов NG-Zorro
• Документация Angular
• Документация NestJS
• Исходники проекта

Публикуем сессию вопросов и ответов о работе с AWS и другими cloud-провайдерами. Сессия прошла в рамках вебинара Создание эффективной инфраструктуры при помощи облачных решений. На Youtube есть запись вебинара, а в блоге мы уже размещали текстовую расшифровку доклада.

Спикер вебинара Александр Волочнев (Developer Advocate в DataStax Inc.) и Всеволод Севастьянов (TechLead в vene.io) ответили на вопросы о прайсе и правах в AWS, рассказали, как защитить данные и в каких ситуациях лучше выбрать российских облачных провайдеров.

Зачем Openstack от %anyvendor% если есть открытая ванильная версия, разрабатываемая огромным количеством талантливых разработчиков?

Всеволод Севастьянов: Вопрос классный, если уточнить, что такое Openstack, так как есть 15 компаний, которые контрибьютят своих разработчиков на разработку непосредственно самого Openstack (HP, IBM и др.). И то, что они себе устанавливают, это по сути есть Openstack для их клауда с какими-то обертками, свистелками от непосредственно самих вендоров. Что выбирать для себя? Вопрос. Если вы берете Openstack, чтобы поставить на свои сервера, берите Openstack, если вам ничего сверху не надо. Если вы будете работать с HP-шными железками или с вещами, которые они вам предоставляют для облачных вычислений, для нейросетей или для коннекшена к облаку самого HP, берите HP-шный Openstack.

Александр Волочнев: Тут я должен сделать шаг в сторону и сказать, что не все знают, что такое Openstack, у нас вебинар для начинающих разработчиков. Openstack это возможность самому сделать свое собственное облако, то есть это такая система управления всяким железом и всем остальным, где с одной стороны сидите вы сами и запихиваете новые сервера, а с другой стороны люди пользуются этим как облаком. Обычно это для больших компаний актуально, где есть отдел, который делает все то же самое, что делает AWS, и есть отдел, который это все обеспечивает. То есть это такое домашнее облако, и есть несколько его поставщиков. Хороший вопрос, на который сложно однозначно ответить. Это как есть Linux Kernel, есть Ubuntu. Несколько холиварная тема, которую я пока что закрываю.

Почему в AWS все так сложно с прайсом? Сложно понять, сколько в итоге будет стоить проект?

Александр: Сложно, потому что AWS это система, которую инженеры создавали для инженеров. А когда инженеры берутся разрабатывать какую-то систему, они думают о том, чтобы все было технически правильно, а не просто. Большой проект иногда бывает проще разработать и внедрить, чем просчитать. Потому что AWS пошло по пути сверхточного вычисления, плюс у каждого сервиса есть отдельные классы, например, у сервиса хранения Simple Storage есть несколько классов хранения файлов. На одном классе хранения файлов у вас файлы будут храниться чуть подороже, но с вас не будут браться деньги, когда их кто-то скачивает, на других классах файлы будут храниться подешевле, но с вас будут браться деньги, когда их кто-то скачивает, причем первые 100 Гб с вас будут брать одну сумму, последующие 100 Гб с вас будут брать другую сумму. При этом, чтобы окончательно всех запутать, есть еще Intelligent Tiering, когда у вас файлы будут прыгать между слоями в зависимости тот того, как будет вам выгоднее, по мнению AWS.

И это я только про хранение файлов говорю в одной конкретной корзине. Если мы говорим про AWS Lambda, бессерверные приложения, там тоже красиво, потому что отдельно считается время, отдельно считаются запуски и отдельно считается потребление памяти в Гб/мс. На самом деле они хотели как лучше. Они хотели предоставить вам оплату потребления только того, что вы действительно потребили. Но поскольку они отдельно считают коннекшены, отдельно потребление, отдельно то-се, пятое-десятое Когда считаете какой-то проект, во-первых, посчитайте, что тарифицируется. Надо учитывать нюансы. Если вы, например, храните маленький файл в их AWS S3 Glacier, ледник служба длительного хранения файлов на магнитных лентах, самое дешевое хранилище, но не самое быстрое, надо учитывать, что там минимальный размер файла считается 100 с чем-то Кб, то есть надо учитывать, что если вы туда положили файл в 1 Кб, платить вы будете как за 100 Кб. Много нюансов, обсчет сложный. Это характерно для продуктов, разработанных инженерами для инженеров.

В защиту AWS скажу, что у них есть очень мощные инструменты для калькуляции. Вы можете запустить калькуляцию, ввести все ваши данные, и вам скажут с точностью до цента, сколько вы потратите. И потратите вы именно столько при условии, что работать будет все именно так, как вы это описали.

Всеволод: Я могу добавить? В защиту AWS хочу сказать, что там данные потребления непосредственно трафика, ресурсов и т.д. берутся с физического сервера. И этот физический сервер может отвечать за несколько типов данных, и этих серверов может быть много, они могут быть объединены в датацентр или колокейшн, разделены по зонам, вы это все используете, все это надо собрать и в конце дня вам доставить. Это непростая задача сама по себе. То есть причины для задержек есть, и они достаточно объективны. Никто не хочет нажиться на бедных разработчиках.

Как избежать чека в $1000, когда ожидаешь максимум $100-200, и при этом не остаться с заблокированным сервисом в час-пик?

Всеволод: Ответ на этот вопрос кроется в твоем предыдущем ответе, Саша. Смысл в том, что, во-первых, надо пользоваться калькулятором, а во-вторых, надо четко понимать, что вы в облаке делаете. Правильный ответ на этот вопрос приходит с опытом использования самого облака. То есть, условно говоря, с опытом вы знаете, что вот для такого функционала вам нужно две машинки С2 и миллион сообщений в SQS, вы ставите такие данные, калькулятор вам выдает число, вы делаете хардкэп на своих сервисах, то есть не больше миллиона сообщений, и отключаете автоскейлинг. Пожалуйста. У вас чек ровно такой, какой вам нужен. Пользуются ли этим в реальной жизни? Не видел еще. Все используют автоскейлинг и очень удивлены.

Александр: У автоскейлинга всегда можно задать верхнюю границу. Теперь мой вариант ответа. Во-первых, все, что сказал Всеволод. Во-вторых, проблема общая, все приходят с этими вопросами. Как избежать чека? Нужно понимать, что вы потребляете, где у вас точки расходов, потому что есть, например, условно бесплатные сервисы. И во всех точках расходов можно задать верхний предел масштабирования. Вы используете AutoScaling groups? Ну, пожалуйста, можно задать максимальное количество серверов, после которого вы согласны падать.

Создавая AutoScaling group, вы задаете минимальное и максимальное значение. Не ставьте там 100 серверов, поставьте 20, если у вас маленький сервис и вы напрямую не монетизируетесь с пришедших клиентов, и то же самое возможно для всех остальных сервисов. Ставьте ограничения, ставьте лимиты. Это вполне себе работает.

Почему так сложно управлять правами доступа в AWS (IAM)? (Прописывание policy вручную, boundary и т.д.)

Александр: Я сначала отвечу на вопрос почему, а потом на вопрос как. Представьте себе на одной стороне отрезка самокат, а на другой самолет, Boieng 777 или что-то подобное. Самокат прост и интуитивно понятен. Вы можете с первого раза встать на него, поехать и через несколько минут с ним справиться, а пару раз набив шишки уже делать какие-то трюки. Порог вхождения низкий, возможности низкие. Вы не можете на самокат посадить себя, своего пьяного друга и два ведра грибов из леса. Мощность низкая, простое управление.

Мы начинаем говорить про мощные системы. Identity and Access Management для тех, кто может быть не знает, это система управления правами доступа в AWS, очень мощная. Она позволяет вам генерировать такие правила, что пользователю Васе разрешено будет использование такого-то сервиса с редактированием при, не знаю, восходящей фазе луны в три часа ночи после крика петуха, но не будет доступно все остальное время, и т.д. Любая мощная система не может быть простой. Это закон природы. Из хороших новостей. Да, порог вхождения высокий, но когда привыкаешь, все становится хорошо. И все эти штуки нужные, хорошие и правильные.

Boundaries в начале можно не использовать. Для небольших проектов они не критичны. Начинайте с простого. В целом описание правил и политики доступа в IAM это очень классная вещь. Ее здорово настраивать. Сложные системы не могут быть с низким порогом вхождения.

Всеволод: Я слышал, что есть определенные тулзы, позволяющие выкинуть ненужные boundaries, policy, которыми ты никогда не будешь пользоваться, сделать это на начальном этапе, накатить это поверх своего аккаунта. Но насколько я понимаю, AWS такие штуки не рекомендует, поскольку это прямой секьюрити брич, и я их тоже не рекомендую. Проще все это освоить, потыкать и поехать.

Александр: Если вы работаете с простым приложением, вам эти навороты не нужны, используйте простой вариант. Если вы инженер, ответственный за это на серьезном проекте, то потратьте один день на то, чтобы изучить, как оно работает. Там не нужно больше одного дня. Восемь часов и читать, читать, смотреть, смотреть. И потом потихоньку внедрять, разбираться на практике. Все. Это не рокет сайнс. Немножко теории и множко практики, все получится.

Почему биллинг облаков до сих пор не работает в реальном времени? Всегда есть риск, что выйдет чек в тысячи долларов.

Всеволод: Мы уже на этот вопрос отвечали. Даже если собрать данные со всех серверов на это уже надо время. Нет такой страшной проблемы. Единственное, следите за вашими ресурсами. AWS играет честно.

Александр: Биллинг любой системы сложнее велосипеда будет отставать, потому что это чертовски сложно. Есть возможность сделать биллинг быстрым. Но ценой потребления ресурсов с вашего сервера. То есть биллинг у вас будет риал-тайм, а сервер будет работать медленнее. Вы точно этого хотите? Всегда есть риск, что выйдет чек в тысячи долларов. Есть. Так вы границы задавайте. Все. Ставьте ограничение, кеширование, тротлинг на API Gateway.

Всеволод: Справедливости ради стоит отметить, что найти эти AutoScaling groups с первого раза сложно, плюс они по умолчанию настроены очень широко.

Александр: Резюмируя: ставьте ограничения, и не будет у вас чеков в тысячи долларов.

Как подстраховаться от политической блокировки в облаке, и насколько оправдано стремление к гибридному облаку?

Всеволод: Можно не делать вендор-локов. Приходя на AWS и зная, что ваш сервис спорный в политическом плане, вы должны знать, что вендор-лок это плохо. Если вы используете SQS, используйте её через какую-то прокладку вашу, которая может переключиться на ту же Кафку, если вы используете что-то амазоновское, думайте о том, как вы это будете быстро мигрировать, а лучше не используйте ничего вообще, ставьте виртуалки, поднимайте на них базы данных, никаких амазоновских сервисов, все только свое и бэкапы всех данных в другое облако или на какой-нибудь свой собственный провайдер.

Александр: Да, избегайте вендор-лока. То есть жесткой привязки к какому-то конкретному поставщику.

Насколько оправдано стремление к гибридному облаку?

Александр: Очень зависит от вашего проекта. Гибридное облако это когда часть проекта у вас запущена в AWS, а часть проекта запущена в вашем собственном датацентре. И они взаимодействуют друг с другом. Насколько это оправдано? Для небольших и средних проектов, я бы сказал, это не оправдано чаще всего. Для больших проектов это может быть оправдано, так как это может быть оптимальным способом уменьшения расходов. Все зависит от вашего юзкейса. Если вы хотите создать максимальную доступность и пережить падение облака, такое тоже возможно. Но это очень сложно, и для этого нужны очень хорошие спецы. То есть снова для большинства проектов это будет неактуальным. Проще, конечно, одно чистое облако. Любые интеграции буду всегда сложнее.

Всеволод: Хотел еще добавить, что решение о внедрении гибридного проекта должен принимать непосредственно технический директор, так как оно несет CAPEX и накладные расходы, в том числе на человеческие ресурсы.

Александр: CAPEX (capital expences, капитальные расходы) подразумевается, что когда компания покупает новые сервера, она тратит много денег, ставит сервера себе как основные средства. И есть OPEX (operational expences), которые относятся к аренде, и если вы целиком в облаке, у вас все расходы на инфраструктуру являются операционными, и они списываются по-другому. Для некоторых компаний это может быть очень важно с точки зрения бухгалтерии и налогообложения.

Как в облаках организована защита критичных для компании данных, интеллектуальной собственности? Или это целиком забота потребителей облачных сервисов?

Александр: Как говорят AWS и, полагаю, Azure тоже: Security is a shared responsibility. Безопасность это разделенная ответственность. Имеется ввиду, что часть безопасности организовывает облако, но как бы они ни старались, если вы со своей стороны о безопасности не позаботились, они вам ничем помочь не смогут. То есть это общая ответственность. Хотите безопасность, изучайте, как организовать безопасность.

И второй момент надо понимать, что с GCP, с Amazon работают очень серьезные американские правительственные компании, у которых сверх строгие требования по шифрованию и хранению данных. И облака регулярно проходят всевозможные виды аудитов, чтобы подтвердить, что у них есть все необходимое: все виды изоляции, все защиты, шифрования и сертификаты все вообще, что может только потребоваться. И для совсем Advanced-кейсов можно использовать Outpost, то есть можно разворачивать инфраструктуру AWS на базе вашего собственного железа.

Всеволод: Я добавлю, что существуют готовые решения для шифрования и защиты ваших данных, в том числе и баз данных. Существует шифрование дисков, которое даже предоставляется бесплатно, насколько я знаю, Гуглом, насчет Амазона я не уверен. В итоге, сможет ли какой-нибудь блэк хэт с улицы залезть в вашу базу данных, зависит только от вас.

Я рекомендую организовывать бастионы, то есть некоторые сервера-прокси, точки входа, изолировать базу данных внутри кластеров, настраивать сервисы Kubernetes так, чтобы они не отвечали ни на что, кроме white-listed IP или white-listed services, ну, и так далее, потому что это большой топик.

Что вы думаете насчет отечественных cloud-провайдеров, Yandex, Selectel? Просто ваше мнение и опыт использования, если есть.

Александр: Здесь все просто. У меня есть небольшое участие в разработке одного из околооблачных поставщиков в России, опыта использования нет, потому что я почти сразу после этого переехал из России и ни про Yandex, ни про Selectel не могу рассказывать.

Всеволод: Последний раз, когда я изучал этот рынок, помимо Яндекса и MCS все остальные провайдеры использовали в некотором смысле openstack-решения. И у них были очень классные решения поверх openstack и очень классный менеджмент. В целом если вы держите бизнес в России, наверное, имеет смысл. У Амазона, например, нет региона Россия.

Александр: Да, у GCP, по-моему, тоже. Если вы держите данные ваших пользователей в России, то Yandex и Selectel могут быть для вас хорошим выбором.

После вашего курса смогу ли я запустить свой проект (небольшой) в AWS c пониманием дела? Смогу использовать нужные абстракции и т. д.?

Александр: Да, безусловно, он для этого и разработан. Я прицеплю сюда еще вопрос ниже: У меня уже есть AWS-SAA01, стоит ли покупать курс Слёрм. Насколько он будет мне полезен? Один из ценных моментов курса возможность задать вопрос и быть услышанным. У Амазона с этим сложно, как правило, такой возможности нет. Я готов взаимодействовать и отвечать на вопросы.

Если вы хотите использовать какие-то сложные вещи, про них мы, может быть, в курсе и не говорим. Например, Амазон предоставляет роскошнейшие возможности для machine learning, у них там все автоматизировано, интегрировано, вообще супер. И это в облаке вообще огонь. Но про это мы не рассказываем в базовом курсе, потому что где базовый курс, а где machine learning? Если вы планируете использовать Fargate, про него мы не рассказываем в базовом курсе, но все стандартные вещи: EC2, S3, AutoScaling, базы данных, Serverly, Lambda, API Gateway, инфраструктура как код, которая помогает вам управлять вашим проектом, и т. д. это все есть.

Почему в России большинство компаний все еще косо смотрит на облака (в пользу in-house инфраструктуры) при всех их преимуществах? Когда ожидать сдвига в мышлении?

Всеволод: Здесь причиной является опыт 90-х годов, когда к тебе в любой момент могли прийти за твоими данными. Уже никто в гости не приходит, но привычка осталась. Возможно, учитывая опыт политических блокировок, держать копию где-то при себе имеет смысл. Большинство компаний будет инвестировать в облака, если вы сможете обосновать их стоимость.

Александр: Нужно время на сдвиг парадигмы, наверное.

Сколько требуется времени для получения опыта или равноценного сертификата, который требуют работодатели для Cloud DevOps Engineer?

Александр: Во-первых, я не знаю, каких сертификатов требуют работодатели для Cloud DevOps Engineer. Если говорить про стандартные младшие позиции, если вы не претендуете на Senior Cloud DevOps, то у меня лично подготовка и сертифицирование для GCP заняла ровно месяц. Мне надо было перенести опыт архитектуры и разработки с AWS на GCP. Но это было много работы, я серьезно по много часов в день вкладывался. Что касается младших должностей, мне кажется, в качестве сайд-проекта базовую сертификацию в направлении Сloud DevOps нужно делать тоже за месяц. Если заниматься этим по паре-тройке часов в день, то это возможно. Это дело интересное и очень неплохо оплачивается в очень многих компаниях.

IAAS не всегда решает вопрос рабочих мест. Есть ли альтернативные способы реализации виртуальных рабочих мест кроме RDS (не гибко) и VDS (дорого)?

Всеволод: Я, честно скажу, в основном использовал облака для разработки приложений, которые там будут хоститься. По поводу организации рабочих мест со всеми RDS, VDS и т.д. здесь сложно ответить. Предлагаю связаться в LinkedIn.

Amazon Outpost. Зачем и как применять?

Александр: Это классная возможность, когда вы можете поднять свой собственный ЦОД, и вы можете запустить весь софт AWS на вашей стороне, и вы будете использовать его как полностью интегрированный в инфраструктуру Амазон, но при этом это будет ваше железо, которое стоит у вас и которое охраняется вами, обеспечивается электричеством вами и т. д. Вот что такое Amazon Outpost. Зачем и как применять? Как применять не расскажу, потому что до сих пор не приходилось, это очень специфичный кейс. У меня нет опыта с Outpost никакого, просто никогда не было необходимости. Зачем? В некоторых ситуациях есть супер-строгие требования по аудиту, системам безопасности и т. д. то есть только у вас должны храниться данные и никуда они не должны попадать, с точки зрения аудита.

Какова разница между курсами Слёрма и AWS training?

Александр: Со своей стороны скажу вот что: AWS я больше изучал на практике и отдельно знакомился с некоторыми курсами, которые у них есть. С точки зрения организации обучения, мне очень понравился Google Cloud Platform. Он вперед на милю от AWS с точки зрения организации процесса, материалов для подготовки и т. д. Первая разница между курсами Слёрм и AWS: AWS на английском. Если у вас плохой английский, Слёрм здесь однозначно будет лучшим выбором. У AWS есть тренинги практически на любую тему. Не всегда полные, не всегда хорошие, но они есть. У Слёрм на данный момент есть только один курс по AWS. Это базовый курс, который закрывает все основные юзкейсы и самые наиболее часто используемые сервисы. Но если вам нужен какой-нибудь хитровывернутый кейс, то этого может не оказаться в нашем курсе, опять-таки, курс называется базовый. И последнее Слёрм обеспечивает определенную поддержку: можно написать, можно сказать, что в практике написано вот так, у меня так не получается, что пошло не так? В AWS Training писать будет некому.

На сколько порядков отличается цена за единицу ресурсов облака для Netflix и стартапа?

Александр: Цена за единицу ресурсов будет одинакова. И это очень классно. Может быть, там есть какие-то секретные скидки для Netflix как глобальной корпорации. Но разные совершенно деньги за потребление.

Где границы между разумным использованием Iaas, PaaS, SaaS?

Александр: Все зависит от того, как много у вас специалистов в этой отрасли, насколько у вас хватает мощностей. Первое правило аутсторса: аутсорсить то, что для вас не принципиально, то, на чем вы не зарабатываете деньги, что не является ключом вашей бизнес-модели. Если вы делаете что-то, что не является для вас принципиальным, это склоняет вас ближе к SaaS. Saas и PaaS очень близки. Вы разрабатываете бессерверное приложение: у вас база данных будет SaaSом, а приложение ваше будет запущено на PaaSе. Я про это рассказываю в восьмом модуле курса. Если у вас много крутейших специалистов, вы Apple, и вы хотите иметь полный контроль над всем железом, то вы ближе к IaaSу или к on-premices собственному датацентру.