AWS — вызов облачного резюме


Справочная информация

Впервые я услышал о конкурсе облачных резюме, когда просматривал сабреддит r/devops. Мне показалось, что это интересный способ улучшить свои навыки работы с AWS. Я недавно получил сертификат AWS Solutions Architect Associate Certate и искал способ практически применить свои новые знания.

SAM

Все началось с AWS SAM и его правильной настройки на моей машине Ubuntu. Включая установку AWS CLI. Я прочитал немного документации по SAM и смог выучить команды для создания простого шаблона бессерверного сервера. К сожалению, я столкнулся с несколькими проблемами, поскольку SAM использует python 3.9, а в моей системе по умолчанию на Ubuntu стоит 3.10. После нескольких поисков в Google и ввода большого количества текста мне удалось установить 3.9 по умолчанию, и я был готов к работе!

Я добавил ведро s3 в свой template.yaml и создал index.html просто для проверки. Я обнаружил, что не могу получить доступ к своему сайту, я получал ошибку 403: Forbidden. После поисков я обнаружил, что это происходит потому, что я не разрешил публичный доступ к моему bucket, так как у меня не было политики bucket, прикрепленной к моему bucket в моем шаблоне. Я настроил политику ведра, развернул свой шаблон и смог прочитать простой «Hello World» в своем веб-браузере.

CloudFront и Route 53

Далее я рассмотрел возможность реализации распределения CloudFront и маршрута Route 53 для моего сайта. В итоге я купил доменное имя непосредственно у Amazon и настроил размещенную зону.

После настройки хостируемой зоны я отредактировал свой template.yaml, чтобы установить хостируемую зону Route 53 на CloudFront. После нескольких ошибок, связанных с взаимодействием хост-зон, я обнаружил, что CloudFront имеет свою собственную хост-зону Z2FDTNDATAQYW2, которая требовалась при подключении Route 53.

Сертификаты, сертификаты, сертификаты!

Я перешел к созданию публичного сертификата для защиты трафика, поступающего в мое распределение CloudFront. Я использовал менеджер сертификатов Amazon и запросил публичный сертификат, затем проверил его, используя запись Route 53 CNAME. У меня было довольно много проблем с тем, чтобы заставить это работать, и мое развертывание SAM постоянно сворачивалось. После поиска в Интернете я обнаружил, что в свойствах сертификата не хватает такого простого параметра, как имя ресурса Amazon Resource Name, что привело к неудачной установке. После включения ARN развертывание прошло успешно, и мой веб-сайт получил SSL-сертификат. Но затем я столкнулся с другой проблемой.

Каждый раз, когда я переходил к своему доменному имени, я получал ошибку 504. Я обнаружил, что если я ввожу прямое имя конечной точки CloudFront, я все равно ничего не получаю. Я перешел непосредственно к конечной точке сайта s3 bucket, и это сработало. Я был в замешательстве и решил снова обратиться к Интернету за ответами.

Оказалось, что конечные точки веб-сайта S3 не разрешают https-трафик непосредственно из CloudFront, а поддерживают только http-трафик. Пользователь, подключающийся к сайту, получает трафик по протоколу https, но трафик от CloudFront к S3 не шифруется. После изменения политики протокола происхождения в моем шаблоне и применения я смог успешно открыть свой сайт, используя доменное имя!

Лямбда и API-шлюз

После настройки CloudFront я обратился к Lambda и API Gateway. Я начал с установки простого JavaScript <скрипта> в моем html-коде.

fetch('https://29sm874uv6.execute-api.us-west-2.amazonaws.com/Prod/helloworld')
            .then(response => response.json())
            .then((data) => {
                document.getElementById('usercount').innerText = data.count
            })

Вход в полноэкранный режим Выйти из полноэкранного режима

Он будет извлекать переменную ‘usercount’ из моего API и выводить ее на экран каждый раз, когда пользователь заходит на страницу. На данный момент это была простая настройка для начала работы, но в дальнейшем она будет пересмотрена.

Затем я настроил базу данных DynamoDB и развернул ее с помощью шаблона CloudFront. Далее я решил разделить свои функции Lambda на две разные функции, которые будут взаимодействовать с моим API-шлюзом. Я отредактировал template.yaml, чтобы разделить базовую функцию helloworld, включенную в SAM, на две разные.

Я начал работать над правильной настройкой DynamoDB, чтобы иметь элементы, из которых мой JavaScript мог бы черпать данные для обновления счетчика посетителей на моем сайте. Здесь я столкнулся с рядом проблем.

Следующая часть задачи The Cloud Resume была, вероятно, самой сложной для меня. Мне нужно было настроить лямбда-функцию для увеличения свойства DynamoDB «visitor_count» моего идентификатора «Visitors». В отчаянном поиске ответов я перелопатил множество документации по boto3 и StackOverflow, но казалось, что все, что я пробовал, не хотело работать. После изучения документации boto3 я нашел несколько полезных примеров, которые я смог вписать в свой код на Python, и это наконец-то сработало! Он начал обновлять мою таблицу DynamoDB каждый раз, когда я перехожу к конечной точке шлюза API.

Вторую функцию было гораздо проще настроить, поскольку я узнал гораздо больше о том, как boto3 взаимодействует с DynamoDB. После создания Python-скрипта для Lambda мне нужно было внедрить его в мой html-код. Эта часть была немного сложнее, так как у меня было очень мало знаний о JavaScript и я не знал, как работает json. После множества проб и ошибок, включавших изменение переменных, изменение html, редактирование и полное изменение типа данных элемента DynamoDB «visitor_count», я продолжал сталкиваться с ошибками форматирования json. Наконец, я нашел дополнительную информацию о json и смог применить ее к моему коду Python, который правильно отформатировал данные для JavaScript в моем html. Я очень обрадовался, когда увидел, что счетчик посетителей обновляется на моей странице!

Действия Github и CI/CD

Конец был близок! Я приступил к настройке Github Actions. Я наконец-то сделал то, что должен был сделать уже давно: использовал Git и создал репозиторий на Github. Я создал папку .github/workflows и некоторое время возился с шаблоном. У меня было несколько проблем, когда каталоги файлов не работали так, как я хотел, в бегунках, и мне пришлось установить определенный рабочий каталог, что решило проблему. Я реализовал несколько базовых тестов на python для моих лямбда-функций.

Я интегрировал свои ресурсы AWS с Github Actions и установил шаблон, в котором в случае успешного тестирования на python запускалось другое действие, которое развертывало инфраструктуру на AWS. Это окончательно завершило внутреннее развертывание моих ресурсов! Далее я поработал над тем, чтобы шаблон развернул мой фронтенд-сайт в ведро S3, реализовав s3-sync-action Джейка Джарвиса. Я проверил, работает ли она после создания шаблона, и, к моему удивлению, она сработала с первой попытки! Я сделал так, чтобы это действие зависело от успешного выполнения сначала моих действий в бэкенде.

HTML и CSS

Наконец, теперь, когда бэкенд был завершен, я начал работать над тем, чтобы мой сайт выглядел красиво. В итоге я купил шаблон от ColorLib, который показался мне хорошим, и внедрил его. В итоге я много возился с html и CSS, пытаясь сделать все так, как я хотел. Так, так, так много <divs> для центрирования.

После того, как все выглядело хорошо, я выложил в свой репозиторий, и все выглядело потрясающе! Я был так счастлив участвовать в этом испытании, даже если я опоздал на пару лет. Оно дало мне столько практических знаний об архитектуре AWS и о том, как работают конвейеры CI/CD. И я не могу забыть об инфраструктуре как коде, там было проделано много работы, чтобы все работало правильно. Даже немного веб-разработки!

Если вы дочитали до конца мои разглагольствования, спасибо, что прочитали, и заходите на мой сайт codykall.com.
Linkedin
Github

Оцените статью
devanswers.ru
Добавить комментарий