Дизайнеры «Стрелки» об айдентике и сайте новой образовательной программы The Terraforming
В начале года в Институте медиа, архитектуры и дизайна «Стрелка» стартовала новая трехлетняя исследовательская программа The Terraforming. Дизайнеры Настя Вишнякова и Даша Лучинина рассказали, как создавались айдентика программы и две версии сайта — для десктопа и мобильная.
903 открытия
The Terraforming — исследовательский проект Института «Стрелка», который обращается к темам преобразования городов, технологий и экосистем Земли, необходимых, чтобы обеспечить продолжение нашей жизни на планете.
Первоначально термин «terraforming» означает преобразование экосистем планет и спутников в пригодные для человеческой жизни, но экологические последствия антропоцена угрожают тем, что скоро его придется применить к самой Земле.
Институт «Стрелка»
Программа Института The Terraforming носит более академический, научный характер, чем предыдущая «Новая норма», и обращается к темам геодизайна, геотехнологий и геоэкономики.
Бенджамин Браттон, программный директор «Стрелки», хотел, чтобы айдентика The Terraforming визуально была связана с советской космической программой, чтобы в ней чувствовались ее мощь и при этом присутствовало немного советской эстетики.
Когда я начала искать референсы, быстро поняла, что в интернете почти не найти нужных мне изображений тех лет, и поехала в павильон «Космос» на ВДНХ. Ходила там и вдохновлялась тем, какой масштабной была советская космическая программа.
По возвращении я разбирала фотографии и пришла к созданию нескольких направлений фирменного стиля. Изначально их было шесть, но в итоге мы показали Бенджамину и команде две концепции, одну из которых они утвердили.
Референсами для принятого варианта стали изображения орбит и траекторий движения ракет и спутников в научных и научно-просветительских журналах. Именно эта графика легла в основу дизайна.
Иллюстрации из книги из Музея космонавтики на ВДНХ
Потом мы добавили в него сетку, которая является частью визуальной ДНК «Стрелки». Кроме того, сетка напоминает о координатной сетке, которая используется в звездной карте.
Тогда же в стиле появились градиенты. В брифе была прописана яркая цветовая палитра. При этом в айдентике The Terraforming цвета — это скорее фон, чем элемент. Они довольно яркие, космические и, как мне кажется, ассоциируются с сай-фаем.
Институт «Стрелка»
Институт «Стрелка»
Шрифт тоже был выбран не случайно. Мы использовали Suisse хорошей швейцарской студии Swiss Typefaces. Этот шрифт — современная интерпретация гельветики. У современного варианта немного другие пропорции и буквы. Гельветика — это 1957 год, то есть примерно то время, в котором мы искали вдохновение. Еще одним из референсов, от которых нам предлагал отталкиваться Бенджамин Браттон, был брендбук Nasa 1976 года. Если его открыть, вы увидите гельветику и типичную швейцарскую сетку. И поэтому мы решили, что современная гельветика нам очень подойдет.
Сайт с описанием программы и формой для подачи заявок на обучение мы сделали на Readymag. При работе над ним решено было делать одну страницу. Так как нужно было дать описание программы, рассказать о поступлении, обучении и о преподавательском составе, информации получилось достаточно много. Ее хватило бы на полноценный сайт с несколькими страницами, но мы разложили ее на одну.
Для разграничения смысловых блоков мы использовали разные цвета. Когда скролишь страницу, один цвет сменяется другим.
Институт «Стрелка»
Институт «Стрелка»
Но когда мы делали мобильную версию лендинга, столкнулись с некоторой сложностью. Если бы мы просто повторили формат подачи информации на сайте, эту страницу пришлось бы скролить до бесконечности. С помощью инструментов Readymag — возможности разделить текст на разделы и инфопоинты — у нас получилось его сократить. Информация раскрывается, когда ты нажимаешь на буллиты.
Анимация в фирменных стилях — стандарт для всех классных студий. Мы хоть и не студия, но тоже ее делаем. В рамках работы над фирменным стилем The Terraforming мы придумали несколько вариантов анимации, один из которых коллеги из отдела разработки собрали для стартовой страницы.
Институт «Стрелка»
Институт «Стрелка»
Формат Readymag предполагает, что за счет некого набора функций на нем можно создать сайт относительно быстро и без участия разработчиков. Но при этом он позволяет интегрировать в этот сайт такие сложные штуки, как 3D-анимацию, и такое сочетание функциональности очень удобно.
С дизайном The Terraforming мы попали в подборку siteInspire, чему, конечно, очень рады.
Для чего вам нужен Terraform? Статья и обучающее видео
Всем большой привет. Меня зовут Виктор, и я DevOps-инженер в команде Nixys. Мы решили выложить обучающее видео, которое будет полезно новичкам в мире DevOps. Тема сегодняшнего туториала — “Знакомство с Terraform”. Также под видео мы поделимся наиболее важными, на наш взгляд, преимуществами этого инструмента.
Кстати, есть небольшая история о том, почему мы вообще решили выкладывать видео. Некоторое время назад мы сняли несколько обучающих видео для внутреннего использования, которые лежали у нас на YouTube — на момент написания статьи мы запилили 7 роликов: 5 на джуна и 2 на мидла. И однажды один из знакомых ребят поделился с нами, что выполнял тестовое задание в одну из IT-компаний по нашим обучающим видео (которые, как мы вообще-то думали, в ПРИВАТНОМ режиме). Благодаря этому слепому случаю мы обнаружили, что количество просмотров некоторых роликов сильно перевалило количество сотрудников компании, а значит даже без нашего ведома приносят некоторую пользу. Так мы решили уже целенаправленно делиться нашими знаниями с более широкой аудиторией (жадничать мы не привыкли).
Итак, видеоролик под названием:
«DevOps с Nixys | Знакомство с Terraform — Tutorial для начинающих #1«.
В создании видео мы пока не волшебники, а только учимся, есть некоторые косяки и шероховатости, просим строго за них не судить, но будем рады советам в комментариях о том, что нам стоит учесть в будущем.
О чём собственно само видео?
В видео демонстрируются возможности особенного подхода к управлению своей инфраструктуры в коде — Infrastructure as Code, или IaC. Как следует из названия, это подход для управления и описания своей инфраструктуры через конфигурационные файлы, а не через ручное редактирование конфигураций на серверах или интерактивное взаимодействие. С помощью замечательного инструмента Terraform мы разворачиваем небольшую облачную инфраструктуру в Yandex Cloud.
Сегодня мы не показываем, как правильно писать код на Terraform, а лишь демонстрируем толику его возможностей. В частности, мы развернули сеть и подсеть, где создали виртуальную машину, к которой привязали настроенную группу безопасности и выделили статичный IP. В самой ВМ мы также произвели настройку примитивнейшего веб-сервера. Кроме того, настроили хранение файла состояния terraform.tfstate в объектном хранилище.
Ну и зачем нам этот ваш Terraform?
Итак, теперь поговорим о том, для чего важен и нужен Terraform, о его преимуществах. Не будем подробно расписывать, что такое Terraform вообще, так как за нас это сделали уже давно — на Хабре есть куча полезнейших статей по теории и практике. Остановимся именно на целесообразности его использования.
- Скорость и уменьшение затрат Поднятие инфраструктуры вручную занимает меньше времени, да. Но только в самый первый раз. Тестовое окружение нужно? Да. И что же, снова поднимать всё то же самое? Вроде и не проблема, но давайте посчитаем: 1) Для простоты возьмем за основу круглые числа (очень условно). Пусть стоимость часа работы инженера = 1000 рублей. Допустим, поднять инфраструктуру руками = 100 часов. Поднять dev окружение = 0,75*100, (инженер же уже набил руку, и второй раз сделает это быстрее). Если нужен stage, то умножаем на два: 2*0,75*100. Итого, на все окружения затрачено — 250 часов и 250 000 рублей. 2) А теперь давайте представим (опять-таки условно), что упал дата-центр и вам снова придётся заплатить за ту же работу 250 000 рублей. Итого, свыше 500 000 рублей + придётся ждать те же 100 часов, чтобы поднять хотя бы prod-окружение, залить данные и запустить его. 3) При использовании Terraform время на поднятие инфраструктуры занимает у всех по-разному, в зависимости от опыта инженера и сложности самой инфраструктуры, но обычно это где-то X2, т.е. 200 часов, плюс стоимость часа работы инженера, который умеет работать с таким инструментом, уже будет выше — например, 1500 рублей. Чтобы поднять test- и stage-окружение нужно лишь поменять несколько переменных в коде — и всё! Я даже не знаю, с каким коэффициентом это считать, пусть будет 0,05*100 (т.е. по 5 часов на одно окружение). Итого — 210 часов, и 315 000 рублей. Пока не так радужно… 4) А если снова смоделировать падение дата-центра? Код у нас остался, поэтому поднять новую инфраструктуру, примерно 6 часов, или почти один рабочий день. Причем большую часть времени займёт восстановление данных из бэкапов (конечно они могут быть гигантских размеров и тогда получится дольше, но тут уж ничего не попишешь). Итог — 321 000 рублей и день простоя 🙂 Да, падение дата-центра — это конечно не самое частое событие, но, во-первых, прецеденты были, а, во-вторых, существует множество других событий и задач (например, любое масштабирование), стоимость которых существенно ниже с Terraform. С ним вы получаете полностью прозрачную инфраструктуру, что позволяет в дальнейшем управлять ею с помощью кода, и из-за этого практически все последующие работы будут выполнены гораздо быстрее и качественнее.
- Исключение человеческого фактора. Допустим, у нас упал сервер. Окей, инженер же поднимал его недавно, ему будет просто все восстановить. Но предположим, прошло много времени и этот инженер уже подзабыл все тонкости или ещё хуже — уволился. Во всех этих случаях потребуется время на ознакомление, череду проб и ошибок. А что же насчет Terraform? В этом и есть его преимущество, если конфигурация написана правильно, то сколько бы времени ни прошло и сколько бы раз вы не запускали terraform apply , результат будет одинаковый. Можно спокойно пересоздать сервер и залить туда свежий бэкап, если требуется. Я не говорю уже про случаи, когда что-то может произойти с дата-центром.
- Стандартизация IaC полностью стандартизирует вашу инфраструктуры, что снижает вероятность ошибок или отклонений. При верном подходе с помощью Terraform практически любой инженер поднимет идентичную инфраструктуру в другом регионе, просто изменив один параметр в конфигурационном файле.
- Контроль версий Подход Infrastructure as Code подразумевает, что инфраструктура хранится в виде кода, соответственно, мы можем применять такую вещь, как система контроля версий, т.е. IaC позволяет документировать, регистрировать и отслеживать каждое изменение конфигурации. Ну прям сказка!
И предвосхищая ещё один ваш вопрос..
Почему бы тогда не нанять высококвалифицированного специалиста, чтобы он написал код? Зачем содержать своего сотрудника или платить другой компании за сопровождение?
Здесь всё просто. Если вы планируете развиваться и выпускать релизы, у вас где-то увеличится нагрузка, где-то возникнет надобность внедрить новый сервис или обновить существующий, и без толкового DevOps-инженера вы просто-напросто не сможете поддерживать свою конфигурацию в актуальном состоянии, и любые нововведения повлекут череду ошибок. В итоге всё равно придётся обращаться к специалисту за помощью, правда в этом случае может быть потеряно драгоценное время, плюс в режиме ASAP стоимость услуг может быть еще и на порядок выше.
Вывод
По нашему мнению, Terraform — это безусловно классная вещь. Да — потребуется более квалифицированный DevOps, да — в начале нужно больше времени, чтобы поднять инфраструктуру, но это отличная инвестиция в будущее.
Спасибо за внимание.
P.S.: Подписывайтесь на наш Telegram-канал DevOps, где мы публикуем новости из мира DevOps.
Основы Terraform
Управление распределенной архитектурой требует значительных трудозатрат и финансовых вложений. Для автоматизации этого процесса можно использовать различные самописные скрипты, но лучше воспользоваться готовыми решениями с открытым исходным кодом. Одним из наиболее известных решений для автоматизации управления инфраструктурой является Terraform. Это Open source решение для управления IaC от компании Hashicorp, разработанное в 2014 году. Решение придерживается декларативного стиля управления инфраструктурой, то есть, вы описываете в конфигурационном файле финальное состояние инфраструктуры, а Terraform приводит её к этому состоянию. В качестве примера можно привести автоматическое развертывание пула виртуальных машин, например для проведения обучения работе с каким-либо ПО.
Ручное создание пары десятков виртуалок может занять целый день, а с помощью Terraform это займет менее часа.
Для того, чтобы описание работы с Terraform не было “сферическим конем в вакууме”, мы в качестве наглядного примера, рассмотрим практический пример создания экземпляра EC2 в AWS.
Язык HCL
Для автоматизации работы с инфраструктурой Terraform использует собственный язык написания конфигурационных файлов Hashicorp Configuration Language (HCL). По сути, этот язык описывает желаемое состояние инфраструктуры в конфигурационном файле.
Сначала немного поговорим о синтаксисе языка HCL. Для описания того или иного создаваемого элемента необходимо подготовить блок, содержащий заключенные в фигурных скобках названия переменных, и их значения, передаваемые функциям.
Как и в большинстве языков программирования, в HCL используются аргументы для присвоения значений переменным. В Terraform эти переменные являются атрибутами, связанными с определенным типом блока. Таким образом, весь код HCL состоит из подобных блоков.
Приступим к написанию конфигурационного файла. В первой строке файла мы указываем слово terraform. Хотя этот параметр считается необязательным, настоятельно рекомендуется его указывать. Далее идет открывающая фигурная скобка. Соответственно в последней строке конфигурационного файла должна быть закрывающая скобка.
terraform
А блок кода может иметь следующий вид:
provider “aws”
А синтаксически правильный, хотя и практически бесполезный вариант всего конфига будет иметь следующий вид:
terraform < provider “aws” < region = “us-west-1” >>
Вот собственно и все, что нам необходимо знать о синтаксисе HCL. Далее немного поговорим о том, как построено хранение конфигурационных файлов в Terraform.
Хранение файлов
Все конфигурационные файлы Terraform должны размещаться в одном каталоге. Так, для того примера, который мы будем рассматривать далее мы можем создать каталог под названием EC2. По умолчанию Terraform предполагает, что все файлы с .tf*расширениями в данном каталоге являются частью конфигурации, независимо от имен файлов.
Для грамотной организации больших конфигурации потребуются три файла:
- variables.tf – для всех объявленных входных переменных.
- provider.tf – для объявленных поставщиков, которых вы используете.
- main.tf – для объявления фактических ресурсов, которые будут созданы.
Однако, такая структура не является обязательной. Мы можем поместить весь наш код в один файл и все будет корректно работать. В рамках примера из сегодняшней статьи мы будем использовать только main.tf.
Далее перейдем к рассмотрению смысловых составляющих кода, то есть к наполнению файлов кодом.
Простой пример
Итак, напомню, наша задача развернуть экземпляр EC2 в облаке AWS. В рамках этой статьи мы будем разворачивать экземпляр только с базовыми настройками. Для более глубокого погружения у нас будет следующая статья.
Теперь давайте подробнее поговорим о том, как подготовить необходимые конфигурационные данные. Прежде всего, нам необходимо определиться с теми провайдерами, которых мы будем использовать. Поскольку мы собираемся развернуть экземпляр EC2 на AWS, нам нужно объявить необходимых поставщиков:
terraform < required_providers < aws = < source = "hashicorp/aws" version >> >
В первой строке, напомним, мы открываем блок terraform, который хотя и не является обязательным с точки зрения синтаксиса системы, но рекомендуется его указывать, особенно когда вы создаете инфраструктуру на удаленной системе.
Вложенный блок required providers, определяет требуемых провайдеров. Нам потребуется поставщик aws с указанными параметрами source и version.
Несколько слов о провайдерах и их взаимодействии с Terraform. Для того, чтобы Terraform поддерживал ту или иную технологию, на серверах Terraform должен быть установлен плагин от соответствующего провайдера, содержащий собственный набор конфигураций, типов ресурсов и источников данных. Здесь можно провести некоторые аналогии с библиотеками в языках высокого уровня.
Далее у нас идет описание самого провайдера, аналогичное примеру, представленному в начале статьи. В поле region мы указываем желаемый регион.
provider "aws"
Значение имеет строковый тип, поэтому оно заключено в пару двойных кавычек ( “” ). Плагин провайдера содержит набор ресурсов, которые мы можем использовать в своей конфигурации. В нашем примере провайдер aws предоставляет ресурс aws_instance, с помощью которого мы создаем экземпляр с именем myec2.
resource “aws_instance” “myec2”
Далее нам необходимо заполнить атрибуты, используемые ресурсом aws_instance. Первый атрибут – ami это идентификатор образа машины Amazon для экземпляра EC2. Второй атрибут instance_type — это атрибут, который определяет размер создаваемой машины. В рамках данной статьи мы не будем подробно рассматривать тему значений экземпляров, отметим лишь, что t2.micro является наиболее дешевым вариантом (надеюсь вы помните, что в облаках за каждый запущенный экземпляр виртуалки нужно платить) для экспериментов с облачными решениями.
С базовыми настройками ресурса мы закончили. Но сейчас мы “приколотили” значения жестко, а для полноценного использования Terraform лучше использовать переменные. Давайте их объявим для тех блоков, которые мы уже рассмотрели.
variable "region" < default = "us-west-1" description = "AWS Region" >variable "ami" < default = "ami-00831fc7c1e3ddc60" description = "Amazon Machine Image ID for Ubuntu Server 20.04" >variable "type"
Мы объявили три переменные region, ami и type. Теперь мы применим значения этих переменных в нашем конфигурационном файле. На значения переменных можно ссылаться с помощью var. .
Но Terraform позволяет не только присваивать значения переменным, но и получать значения, после преобразований, с помощью функции output.
Соберем нашу конфигурацию в виде единого файла main.tf .
terraform < required_providers < aws = < source = "hashicorp/aws" version >> > provider "aws" < region = var.region >variable "region" < default = "us-west-1" description = "AWS Region" >variable "ami" < default = "ami-00831fc7c1e3ddc60" description = "Amazon Machine Image ID for Ubuntu Server 20.04" >variable "type" < default = "t2.micro" description = "Size of VM" >resource "aws_instance" "myec2" < ami = var.ami instance_type = var.type tags = < name = "Demo System" >> output "instance_id"
Сохраним данную конфигурацию в файле и перейдем к выполнению команд для работы с Terraform.
Три основные команды
Перед началом применения нашей конфигурации необходимо инициализировать провайдера и установить плагин AWS. Это можно сделать с помощью команды:
Результатом успешного выполнения команды является сообщение об успешной инициализации, аналогичное приведенному на рисунке.
После этого нам необходимо произвести валидацию подготовленного ранее конфигурационного файла. За выполнение этой задачи отвечает команда
В случае, если валидация прошла успешно и никаких ошибок выявлено не было, мы можем применить нашу конфигурацию с помощью команды
Результатом успешного выполнения этой команды будет создание экземпляра EC2 в облаке Amazon.
Заключение
Как видно, работать с кодом в инфраструктуре IaC не слишком сложно. Однако сегодня мы рассмотрели только базовый пример создания экземпляра и многие интересные функции HCL пока остались за кадром.
В следующей статье мы усложним нашу инфраструктуру, наделив нашу создаваемую виртуальную инфраструктуру различными полезными настройками.
Статья подготовлена в преддверии старта курса DevOps практики и инструменты. Узнать подробнее о курсе и зарегистрироваться на бесплатный урок можно по ссылке ниже.
При подготовке материала использовались источники:
https://vc.ru/design/107500-dizaynery-strelki-ob-aydentike-i-sayte-novoy-obrazovatelnoy-programmy-the-terraforming
https://habr.com/ru/companies/nixys/articles/692138/
https://habr.com/ru/companies/otus/articles/696694/