По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В этой статье расскажем о различных концепциях и стратегиях, которые реализуют многие организации для защиты своих активов как от внутренних, так и от внешних киберугроз.
Вы узнаете об этих трех основных принципах, и о том, как они используются в различных организациях. Кроме того, вы узнаете о ключевых терминах безопасности и моделях контроля доступа.
При подключении устройства к сети и Интернету, организации открывают двери для хакеров, которые могут проникнуть в их сеть и нанести ущерб. Есть много организаций, которые используют только брандмауэр в своей сети и поэтому думают, что и их внутренняя сеть, и пользователи защищены от угроз в Интернете. Брандмауэр, как единственное сетевое устройство, развернутое между внутренней сетью и Интернетом, — это просто первый уровень безопасности для всей организации. Многие люди задаются вопросом: а не достаточно ли брандмауэра для фильтрации вредоносного входящего и исходящего трафика?
Много лет назад ответ был бы однозначно «да». Однако, поскольку хакеры всегда ищут новые стратегии для проникновения в сеть, мы не можем полагаться только на один уровень безопасности для защиты наших активов. Ответ на этот вопрос уже не является однозначным «да» просто потому, что существует много типов трафика, которые используют небезопасные сетевые протоколы для обмена сообщениями между источником и получателем.
Ниже приведены лишь некоторые из многих вопросов, которые должен задать специалист по кибербезопасности:
Осуществляет ли организация активный мониторинг сообщений Domain Name System (DNS) на предмет угроз?
Есть ли в организации какие-либо решения для обеспечения безопасности, защищающие входящие и исходящие сообщения электронной почты компании?
Если в сети происходит кибератака, существуют ли системы для упреждающего блокирования и оповещения отдела информационных технологий?
Есть ли в организации специальная группа или человек по безопасности для управления общей безопасностью всего предприятия?
Существуют ли какие-либо политики безопасности и технические средства контроля для защиты внутренней сети?
Многие поставщики систем безопасности используют маркетинговые стратегии и используют модные слова (buzzwords), чтобы повлиять на потенциальных клиентов для приобретения их устройств безопасности «все в одном». Ключевой момент, который упускают многие не осведомленные клиенты, — это то, как решение или продукт безопасности будет защищать всех пользователей и все типы трафика, защищать их при использовании небезопасных протоколов и так далее. Примером может служить использование endpoint protection (защиты конечных точек). Вы можете рассматривать это решение как антивирусное программное обеспечение с централизованным управлением для администратора. Хотя многие решения для защиты от вредоносных программ конечных точек предлагают расширенные функции. Это все еще первый уровень безопасности, который просто защищает хост.
Не все решения для защиты конечных точек или антивирусы, защищают от угроз, связанных, например с электронной почтой. Проще говоря, организация не может полагаться только на один подход для защиты своих активов, ей нужен многоуровневый подход, известный как Глубокая защита (Defense in Depth - DiD).
Стратегия DiD подразумевает, что один уровень безопасности не должен использоваться в качестве единственной меры противодействия кибератакам. Если этот единственный уровень не сможет защитить сеть, тогда все (активы) будут открыты для взлома хакерами. В DiD реализован многоуровневый подход для защиты всех активов от различных типов кибератак, где, если один уровень не может защитить актив, то есть другой уровень для обеспечения безопасности.
Эту тактику наслаивания придумали в Агентстве национальной безопасности (NSA) как комплексный подход к информационной и электронной безопасности. А изначально - это военная стратегия, которая направлена на то, чтобы заставить атакующего тратить как можно больше времени на преодоление каждого уровня защиты, нежели предотвратить наступление противника.
Концепция Defense in Depth делит организацию защиты инфраструктуры на три контролируемые части:
Физическая: сюда относятся все меры по ограничению физического доступа к ИТ-инфраструктуре неавторизованных лиц. Например, охранник офиса, системы СКУД, камеры видеонаблюдения, сигнализация, телекоммуникационные шкафы с замками и так далее.
Техническая: сюда относятся все хардварные и софтовые средства защиты информации, призванные контролировать сетевой доступ к объектам информационной системы, межсетевой экран, средства антивирусной защиты рабочих станций, прокси-серверы, системы аутентификации и авторизации.
Административная: сюда относятся все политики и процедуры информационной безопасности, принятые в организации. Данные документы призваны регулировать управление защитой, распределение и обработку критичной информации, использование программных и технических средств в компании, а также взаимодействие сотрудников с информационной системой, сторонними организациями и другими внешними субъектами.
Многоуровневый подход -это как защита короля в его замке. Если произойдет нападение, захватчикам потребуется пройти несколько уровней обороны, включая стражей на входе и другие препятствия, прежде чем они смогут добраться до короля (актива).
Чтобы лучше понять важность DiD, давайте углубимся в изучение трех основных принципов информационной безопасности, так называемой триады CIA:
Конфиденциальность (Confidentiality)
Целостность (Integrity)
Доступность (Availability)
Каждый принцип играет жизненно важную роль в обеспечении информационной безопасности любой организации. В следующем подразделе вы узнаете о характеристиках конфиденциальности, целостности и доступности, а также о том, как они используются в отрасли для обеспечения безопасности наших сетей.
Конфиденциальность
Поскольку все больше людей подключаются к сетям и обмениваются информацией, будь то их частная сеть дома, корпоративная сеть в офисе или даже Интернет, конфиденциальность является серьезной проблемой.
Каждый день организации генерируют новые данные, отправляя и получая сообщения между устройствами. Представьте себе организацию, которая использует электронную почту в качестве единственной платформы обмена сообщениями. Каждый человек создает сообщение электронной почты, которое является данными, и эти данные используют некоторое пространство для хранения в локальной системе. Когда адресат получает электронное письмо, оно сохраняется на компьютере получателя. Важно, чтобы сообщение получили только те, кому оно адресовано, посторонние лица его увидеть не должны.
Когда эти данные передаются по сети, их также можно перехватить. Поэтому специалист по безопасности также должен принимать во внимание следующие вопросы: является ли соединение безопасным? Является ли протокол связи безопасным? Является ли сеть безопасной?
Конфиденциальность (Confidentiality) гарантирует, что сообщения и другие данные будут храниться в тайне от посторонних лиц или устройств. В области информационных технологий конфиденциальность реализуется в виде шифрования данных. Люди используют устройства для выполнения задач, будь то отправка электронной почты, загрузка файла или даже отправка сообщения в мессенджере со смартфона. Важно всегда защищать эти сообщения.
Данные обычно существуют в следующих состояниях:
Данные в состоянии покоя
Данные в движении (транзит)
Используемые данные
Данные в состоянии покоя — это данные, которые не используются ни приложением, ни системой. В данный момент они хранятся на носителях, таких как жесткий диск (HDD) в локальной или удаленной системе. Когда данные находятся в состоянии покоя, они уязвимы для злоумышленников, пытающихся либо украсть, либо изменить их. Специалисты по безопасности реализуют как методы аутентификации, так и алгоритмы шифрования для защиты любых данных в состоянии покоя. Примером может служить использование BitLocker в операционной системе Microsoft Windows 10, которая позволяет администратору создавать зашифрованный контейнер, а затем пользователь может поместить файлы в эту специальную область памяти и заблокировать ее.
После того, как содержимое BitLocker заблокировано (закрыто) пользователем, и контейнер, и его содержимое шифруются. Следовательно, доступ предоставляется только в том случае, если пользователь предоставляет правильные учетные данные для открытия и расшифровки содержимого. Если злоумышленник украдет зашифрованный контейнер, он не сможет просмотреть содержимое из-за шифрования данных.
Данные в движении определяются как данные, которые передаются между источником и пунктом назначения. Представьте, что есть сотрудники, которые работают дистанционно или работают в удаленном месте вдали от офиса. Этим людям может потребоваться часто подключаться к корпоративной сети для доступа к сетевым ресурсам, например, при доступе или работе с документами, находящимися на файловом сервере. Как специалисты в области кибербезопасности, мы должны быть осведомлены о том, какие типы защиты или механизмы безопасности существуют для защиты данных, передаваемых между устройством пользователя и файловым сервером. Кроме того, устройства отправляют и получают сообщения почти каждую секунду, и некоторые из этих сообщений обмениваются с использованием небезопасных протоколов, что позволяет злоумышленнику перехватывать сообщения (данные) по мере их передачи по сети. Если данные передаются по сети в незашифрованном формате, злоумышленник может увидеть все содержимое в виде открытого текста и собрать конфиденциальную информацию, такую как логины и пароли.
Это всего лишь несколько возможных ситуаций, которые могут возникнуть, когда данные находятся в движении. Некоторые рекомендуемые действия заключаются в том, чтобы всегда, когда это возможно, использовать защищенные сетевые протоколы и гарантировать, что удаленные сотрудники, используют виртуальную частную сеть (VPN) для шифрования трафика между устройством пользователя и корпоративной сетью.
Чтобы лучше понять необходимость VPN, представьте, что организация имеет несколько филиалов и хочет «расшарить» ресурсы из головного офиса в удаленный филиал. Использование Интернета небезопасно, особенно для передачи корпоративных данных между филиалами. Одним из решений может быть использование Wide Area Network (WAN), предоставляемой интернет-провайдером (ISP). Если организация решает использовать WAN, это означает, что за эту услугу придется платить, а для некоторых компаний это решение может оказаться не по карману. В качестве альтернативы, если организация имеет подключение к Интернету и брандмауэры находятся в каждом офисе, специалист по безопасности может настроить VPN между двумя устройствами брандмауэра. Этот тип VPN известен как site-to-site VPN.
На следующем рисунке показано представление site-to-site VPN:
Как показано на рисунке, site-to-site VPN устанавливает безопасное зашифрованное соединение между головным офисом и удаленными филиалами через Интернет. Следовательно, любые сообщения, которые перемещаются между офисами, шифруются и отправляются через туннель VPN, защищая сообщения от неавторизованных пользователей.
Существует также другой тип VPN - с удаленным доступом (remote access VPN). Этот тип позволяет пользователю установить VPN-туннель между конечным устройством, таким как ноутбук, и брандмауэром организации. Этот тип VPN позволяет сотрудникам, работающим дома или на ходу, безопасно подключаться к сети организации и получать доступ к сетевым ресурсам. Имейте в виду, что на устройстве сотрудника должен быть установлен VPN-клиент, который используется для установления безопасного соединения между компьютером и корпоративным брандмауэром.
На следующем рисунке приведен пример VPN с удаленным доступом:
Используемые данные — это данные, к которым в данный момент обращается или использует приложение. В этом состоянии данные наиболее уязвимы. В качестве примера используемых данных представьте, что вы открываете PDF-документ с помощью приложения для чтения PDF-файлов. Прежде чем приложение сможет успешно открыть файл PDF, документ необходимо расшифровать, если файл защищен паролем. После ввода правильного пароля документ будет представлен пользователю в незашифрованном виде. Важно обеспечить постоянную безопасность системы и приложений, которые обращаются к данным и/или используют их.
Таким образом, конфиденциальность — это защита ваших активов от посторонних лиц или устройств.
Целостность
Целостность (Integrity) играет важную роль в нашей повседневной жизни, это степень сформированности, собранности, проявление гармонии соотношения и взаимодействия частей. Вышло немного по-философски, но тот же принцип необходим и в сети. Представьте, что вы получили письмо от друга через местное отделение почты и открыв его, кажется, что с его содержимым все в порядке. Как получатель, вы могли бы предположить, что содержимое письма осталось неизменным в процессе доставки, но как вы можете проверить, было ли содержимое изменено человеком или устройством по пути? В сети очень важно обеспечить, чтобы данные или сообщения не изменялись в процессе передачи между источником и получателем.
В кибербезопасности используются специальные алгоритмы хеширования, чтобы помочь пользователям и устройствам проверить, было ли сообщение изменено или нет при его передаче. Алгоритмы хеширования создают односторонний криптографический хэш (дайджест, он же контрольная сумма), который является математическим представлением сообщения. Это означает, что только это сообщение может выдавать одно и то же хэш-значение. Алгоритмы хеширования создают одностороннюю функцию, которая делает практически невозможным изменение и определение содержимого самого сообщения.
На следующем рисунке показан процесс хеширования сообщения:
Как показано на рисунке, сообщение проходит через криптографический алгоритм, который создаёт одностороннюю хэш-функцию сообщения. Когда пользователь или устройство хочет отправить сообщение адресату, и сообщение, и его хеш-значение упаковываются вместе и отправляются по сети. Когда получатель получает входящее сообщение, он выполняет свою собственную функцию хеширования сообщения и вычисляет его хеш-значение.
Затем получатель сравнивает хеш-значение, полученное от отправителя, с хеш-значением, которое он высчитал. Если оба значения хеш-функций совпадают, это означает, что сообщение не было изменено во время передачи и целостность сохранена. Однако, если хэши не совпадают, это указывает на то, что сообщение было подвергнуто изменению, и получатель просто удалит его.
Помимо этого, хэширование также помогает убедиться в том, что сообщение не было искажено в результате каких-либо сбоев или неполадок в сети.
Доступность
Существуют типы кибератак, которые блокируют или затрудняют доступ законных пользователей к ресурсу. Другими словами, злоумышленники пытаются нарушить доступность (availability) данных и ресурсов. В области кибербезопасности доступность гарантирует, что данные и ресурсы всегда доступны для пользователей и систем, которым разрешен доступ к этим ресурсам.
Простым примером кибератаки, которая может быть использована для нарушения доступности сети, является атака «распределенный отказ в обслуживании» Distributed Denial of Service (DDoS). Этот тип атаки запускается из нескольких географических точек и нацелен на одну систему или сеть. Злоумышленник направляет к объекту атаки огромное количество легитимных запросов или другого типа трафика, в результате чего, система перегружается и становится неспособной обработать запросы от других пользователей. Цель состоит в том, чтобы сделать целевую систему или сеть непригодными для использования или недоступными для других пользователей.
Cloudflare (www.cloudflare.com) обеспечивает неограниченную защиту от DDoS-атак для пользователей. Администратор может перенести свои записи DNS в Cloudflare для управления службами DNS. Таким образом, Cloudflare находится между общедоступным сервером и остальной частью Интернета. Если на ресурс будет направлен DDoS-трафик из любой точки мира, он должна будет проходить через сеть Cloudflare, что смягчит атаку.
Возможно вы считаете, что для злоумышленников важно, чтобы сетевые ресурсы и данные были всегда доступны, чтобы их можно было взломать или украсть. Но на самом деле существуют злоумышленники, цель которых - сделать так, чтобы эти ресурсы не были больше доступны для пользователей.
Просто представьте что злоумышленник взломает систему управления энергосистемой вашего города или района. Если хакеру удастся отключить эту систему, то не будет электричества, и это затронет большинство потребителей и организаций. В таких ситуациях важно, чтобы специалисты внедрили меры безопасности, которые смогут защитить критически важные процессы, системы и сети от взлома.
Объединение трех принципов
Некоторые организации ставят одни принципы выше других. Например, компания может больше внимание уделять на защите своих данных с помощью различных систем аутентификации и шифрования. Этот принцип фокусируется на конфиденциальности. Сосредоточение внимания на одном компоненте, таком как конфиденциальность, в большей степени, чем на других, повлечет меньшее внимание к другим - целостности и/или доступности.
Вы можете задаться вопросом: и в чём здесь проблема? Представьте себе, что организация применяет самые строгие меры безопасности для предотвращения любого несанкционированного доступа к своим системам и сети. Чтобы авторизованный пользователь мог получить доступ к этим ресурсам, ему необходимо будет предоставить, возможно, несколько проверок своей личности, например, при многофакторной аутентификации (MFA), и даже пароли для открытия файлов. В результате доступ к ресурсам будет усложнен для всех, включая авторизованных пользователей, поэтому доступность немного пострадает.
На следующем рисунке показана триада принципов и точка фокусировки в центре:
Ключевой момент заключается в том, чтобы всегда обеспечивать баланс при реализации конфиденциальности, целостности и доступности в любой системе и сети. Важно уделять одинаковое внимание всем основным направлениям просто для того, чтобы не было недостатка ни в одном аспекте информационной безопасности.
В этой статье мы познакомим вас с популярной профессией DevOps-инженера и расскажем, что он делает, как им стать, где искать работу и – самое главное – сколько можно зарабатывать. В отличие от некоторых модных карьерных направлений, которые появляются и исчезают, DevOps — это область, которая была и будет востребованной.
Согласно прогнозам
, к концу 2023 года рынок DevOps вырастет до невероятных $10.3 млрд, так что получение должности DevOps-инженера — это ваш первый шаг к долгосрочной карьере.
Если вам нужна работа, сочетающая технологии и творческий подход, то должность DevOps-инженера — это для вас! В этой статье расскажем, как стартовать в этой сфере и что о ней следует знать.
Кто такой DevOps-инженер
Это специалист, на чьих плечах лежит ответственность за совершенствование и автоматизацию процессов разработки и эксплуатации программного обеспечения. Проще говоря, это методология, объединяющая разработку (Dev) и эксплуатацию (Ops) в разработке программного обеспечения с акцентом на скорость и качество. Задача DevOps-инженера состоит в том, чтобы наладить коммуникацию и сотрудничество между этими двумя направлениями.
Что делает DevOps-инженер
DevOps-инженер отвечает за создание инструментов, улучшающих процессы разработки, повышение производительности, надежности и безопасности программных продуктов. Ключевые области занятости devops-инженера включают в себя:
автоматизацию развертывания и масштабирования систем,
управление инфраструктурой как кодом (IaC),
непрерывную поставку и интеграцию (CI/CD),
мониторинг и логирование,
управление конфигурацией и изменениями,
работу с облачными платформами и микросервисной архитектурой.
Где работать DevOps-инженеру
DevOps-инженеры востребованы в различных сферах и отраслях. Они могут работать как в крупных корпорациях, так и в стартапах, где процессы разработки носят более гибкий и динамичный характер. DevOps-подход активно внедряется в современных IT-компаниях, разработчиками облачных решений, а также в корпоративных IT-отделах.
Профессионал в этой области может работать как в операционных подразделениях, так и в команде разработки ПО.
Необходимые навыки для DevOps-инженера
Помните, что DevOps — это не просто набор инструментов или название должности. Это группа скиллов, в которой особое внимание уделяется командной работе, коммуникации и автоматизации. Рассказываем подробнее о каждом из них:
навыки программирования: специалист должен обладать опытом в программировании на языках, таких как Python, Ruby, Go, Java, Rust, C и C++. Проще говоря, он должен уметь писать код, который автоматизирует процессы разработки и операционной работы.
навыки работы с системами контроля версий: DevOps-инженер должен знать, как работать с системами контроля версий, такими как Git. Он также отвечает за управление конфигурацией серверов и инфраструктуры.
навыки работы с облачными технологиями: специалист должен уметь работать с AWS, Azure или Google Cloud. Он должен уметь настраивать инфраструктуру в облаке и управлять ресурсами.
навыки автоматизации: DevOps-инженеру требуется автоматизировать процессы разработки и операционной работы. Он должен знать, как настроить CI/CD-пайплайны, тестирование и деплоймент.
навыки мониторинга и логирования. DevOps-инженер должен уметь анализировать логи и метрики, чтобы быстро реагировать на проблемы.
навыки коммуникации. Специалист должен уметь общаться с разработчиками, тестировщиками и операторами. Он должен быть готов к сотрудничеству, давать понятные ТЗ и уметь объяснять сложные технические вопросы простым языком.
В рамках DevOps вы будете участвовать во всем цикле разработки ПО — от планирования до внедрения. Как правило, работа в качестве DevOps начинается с должности начального уровня, например, релиз-менеджера или младшего инженера. По мере накопления опыта внедрения инструментов и процессов, можно вырасти: и стать DevOps-инженером, архитектором или системным инженером.
Чтобы построить карьеру в качестве DevOps, вам потребуется техническое образование в области информатики или информационных технологий, а также понимание Linux, веб-разработки и Java. Поскольку DevOps охватывает весь жизненный цикл программного обеспечения, вместо того чтобы сосредоточиться на одной области, инженеры DevOps работают над оптимизацией каждого этапа процесса. Это означает, что они будут решать множество задач в день, попутно находя точки роста для продукта.
Плюсы и минусы профессии DevOps-инженера
Поскольку
86% организаций
считают необходимым быстро разрабатывать новое программное обеспечение, вклад DevOps в компанию очень большой. Давайте рассмотрим, какие плюсы у этой работы есть для вас как для сотрудника:
1. Высокий спрос на рынке труда: инженеры востребованы во многих компаниях, в том числе и зарубежных. Именно поэтому DevOps стала
такой популярной
методологией разработки во всем мире.
2. Высокая зарплата: DevOps-инженеры могут получать от 70 до 600 тысяч рублей — доход всегда растет вместе с умениями и опытом.
3. Большой выбор инструментов: DevOps-инженеры могут использовать широкий спектр инструментов для автоматизации и управления процессами.
5. Быстрый рост в карьере: при условии постоянного обучения и оттачивания технических скиллов DevOps-инженер может продвигаться по карьерной лестнице, не сидя годами на одной зарплате.
К тому же, эта роль предполагает работу с другими техническими специалистами, фреймворками, языками программирования, так что вы получите глубокое понимание экосистемы DevOps — и это тоже поможет росту в долгосрочной перспективе.
Минусы:
1. Высокие требования к знаниям и навыкам. DevOps-инженеру необходимо постоянно обучаться и развиваться, чтобы оставаться востребованным.
2. Большая ответственность. DevOps-инженер отвечает за автоматизацию процессов разработки и операционной работы, что может повлечь за собой серьезные последствия в случае ошибки или сбоя..
3. Необходимость быстро реагировать. Специалист должен быть готов к быстрому реагированию на изменения в проекте или системе, чтобы ничего не «рухнуло».
4. Высокая конкуренция. Чтобы получить работу DevOps-инженером, понадобится подтвердить свои технические навыки и софт-скиллы. Поможет и обучение в техническом ВУЗЕ или на
профильных курсах
.
5. Овертаймы или необходимость работать ночью. В некоторых случаях DevOps-инженер может столкнуться с тем, что ему придется выходить в ночные смены, чтобы обеспечить бесперебойную работу системы, либо задерживаться на работе. Такие моменты можно обсудить с руководством и договориться о дополнительной оплате.
DevOps-инженер: зарплата и вакансии
Зарплата DevOps-инженера в России может значительно варьироваться в зависимости от опыта работы, компании, региона и других факторов.
По данным HeadHunter
, средняя зарплата DevOps-инженера в России составляет около 130 000 — 150 000 рублей в месяц. В Москве и Санкт-Петербурге зарплаты могут быть выше и составлять от 150 000 до 200 000 рублей в месяц.
Учитывайте, что зарплата может зависеть от уровня опыта и квалификации.
Новички
в этой области могут начинать с зарплаты 70 000 — 80 000 рублей в месяц, тогда как опытные DevOps-инженеры могут зарабатывать
более 250 000
рублей в месяц.
Как стать DevOps-инженером с нуля
Будущее профессии DevOps-инженера выглядит блестящим. Возможно, после прочтения статьи вам показалось, что нужно обладать огромным количеством навыков для обучения этой профессии. Но это не так: начать карьеру DevOps-инженера с нуля можно и даже нужно! Важно выбирать учебные программы, которые охватывают не только основы DevOps, но и практику применения современных инструментов автоматизации, управления конфигурацией и работы с облачными платформами.
У нас есть курс
«DevOps-инженер с нуля»
, где вы научитесь использовать инструменты и методы DevOps для автоматизации тестирования, сборки и развертывания кода, управления инфраструктурой и ускорения процесса доставки продуктов в продакшн.
Что в итоге
У IT-компаний, которые наращивают скорость и эффективность DevOps, сочетая его с другими технологиями, есть потенциал стать лидерами — как в плане технологий, так и в плане доверия клиентов.
DevOps-инженер способен повысить качество выпускаемого ПО, улучшить его безопасность и наладить отношения с пользователями. Карьерные возможности, высокие зарплаты и постоянно растущий рынок труда делают профессию привлекательной для тех, кто стремится растить свои навыки в IT.
Помните, что единственный способ продвинуться в любой карьере — постоянно быть в курсе последних тенденций и технологий в этой области. Это не только поможет вам быть в курсе новостей сферы, но и поможет получить лучшую работу и зарплату.
В данной статье посмотрим и разберем, как создать простейшие ресурсы в облаке AWS (Amazon Web Services) с помощью замечательного инструмента IaaS, под названием Terraform. Для того, чтобы можно было повторить то, о чем пойдет речь в статье необходим действующий аккаунт AWS и рабочая машина (виртуальный сервер) с установленным Terraform, и текстовым редактором Atom + плагин для Terraform.
Первоначальная настройка данных инструментов разбиралась в предыдущих статьях. Описание в статье пойдет под операционную систему CentOS. Вы можете для тренировки использовать на свой вкус любую.
Для начала создадим папку под наш новый проект, можно непосредственно в домашней директории.
sudo mkdir terraform
Создадим первый файл нашего терраформ кода. Можно создать непосредственно в редакторе, через меню или в командной строке sudo touch myterr.tf. Принципиальной разницы, как будет создан файл нет. Если создали через командную строку открываем, как обычный файл в редакторе.
Далее схема работы следующая: пишем код в файле, сохраняем, производим управляющие команды в командной строке для выполнения или проверки данного кода, уничтожения, модификации элементов или объектов в облаке.
Как в начале статьи было сказано, нам необходим аккаунт AWS, чтобы терраформ взаимодействовал с облачной инфраструктурой, а более конкретно нам нужно создать пользователя и получить access key и secret key, для доступа к облаку. Это необходимо для аунтификации Terraform в AWS облаке.
Заходим в AWS консоль и выбираем сервис IAM. Заходим во вкладку пользователи и создаем новую учетную запись. Вводим имя пользователя в пустое поле. Нужно поставить Programmatic Фccess. Далее нажимаем Создать пользователя и попадаем на закладку назначения прав. Тут необходимо присоеденить уже созданный по умолчанию в AWS набор прав администратора. Далее переходим к страничке назначения Tag, тут по желанию вашему, если хотите то можете добавить тэги. Нажимаем кнопку создать пользователя.
Финальное окно будет выглядеть следующим образом.
Получаем те данные, которые нам необходимы для Terraform.
Очень важно - Secret key показывается только один раз!
Теперь в принципе все готово для создания первого ресурса в AWS.
Начинаем с объявления с каким облаком мы работаем.
provider “aws” {
}
Тем самым мы обозначили с каким облачным провайдером мы будем работать. В данном коде в отличии от YAML, количество пробелов не важно. Далее прописываем access key и secret key. В каком регионе будут использоваться ресурсы. Регион мы укажем eu-central-1 – это ЦОД расположенный в Европе во Франфуркте. Старайтесь регион указывать, поближе к себе, чтобы до ресурсов была минимальная задержка прохождения пакетов.
provider “aws” {
access_key = “тут ключ доступа”
secret key = “тут секретный ключ”
region = “eu-central-1”
}
При нажатии Ctrl+S, мы сохраняем и видим, что плагин аккуратно выправляет для удобства написанный код.
Теперь можно сделать первый ресурс. Например, инстанс в Амазон. Добавляем ниже:
resource “aws_instance” “my_название” {
ami = “”
instance_type = “”
}
Для поднятия ресурса необходимо указать 2 минимальные вещи. Это ami – image id и instance_type. Теперь необходимо пойти в указанный регион, открыть EC2 и посмотреть ami интересующего инстанса.
А тип возьмем t2.micro. Данный тип для новых аккаунтов на год бесплатный. Получаем код полностью готовый для развертывания первого инстанса.
В принципе все готово для запуска первого инстанса. Код Terraform будет выглядеть следующим образом:
provider “aws” {
access_key = “тут ключ доступа”
secret key = “тут секретный ключ”
region = “eu-central-1”
}
resource “aws_instance” “TestUbuntu” {
ami = “ami-0767046d1677be5a0”
instance_type = “t2.micro”
}
Запускаем консоль и переходим в директорию, где находится у нас Terraform.
Далее есть небольшой нюанс запуска, чтобы в коде не светить свои access_key и secret_key, эти данные можно убрать, экспортировав в переменные. Делается это следующим образом. С помощью команды export.
export AWS_ACCESS_KEY_ID=ключ
export AWS_SECRET_ACCESS_KEY=ключ
И можно убирать эти 2 строчки из кода.
Теперь запускаем Terraform. Первая команда, которую необходимо сделать это команда terraform init, данная команда пройдется по всем tf файлам, она увидит провайдера и скачает дополнительные файлы, необходимые для запуска в том числе и бинарники. Сам Terraform – это такая оболочка, которая подкачивает все, что ей необходимо.
Следующая команда, которая понадобится это terraform plan, данная команда позволяет посмотреть, что Terraform будет делать. Т.е нечто вроде Whatif. Данная команда очень важна т.к в крупных проектах, позволяет заранее посмотреть, что будет если мы запустим файл терраформа. Вывод ее большой, кусочек представлен на картинке.
Можно увидеть, что добавится. Достаточно удобно. Как мы видим, при команде на deploy, Terraform добавит в амазон 1 instance, т.е 1 виртуальную машину из указанного шаблона, указанного типа и размера.
Непосредственно для deploy, необходимо ввести команду terraform apply, прочитать что Terraform будет делать и явным образом, командой yes подтвердить.
После подтверждения видим следующую картину. Со стороны консоли.
Со стороны амазона спустя полминуты.
Как мы видим сервер создался и проходит инициализацию.