AWS - доступ к сервисам внутри VPC (Cognito, RDS, Secrets Manager, SQS, IoT).
Предупреждаю заранее, чтобы вы не читали мой «роман», думая, что это учебник. Эта статья больше о моей истории на работе и краткий рассказ об изучении новых технологий и приключениях в неизведанных областях, чем учебное пособие. Я расскажу о некоторых проблемах, которые у меня возникли с AWS, и это определенно может быть очень полезно для вас, но это немного позже.
Около шести месяцев назад я начал работать в технологической компании в качестве одного из разработчиков программного обеспечения. Компания под названием Fingermark работает с ресторанами быстрого обслуживания (QSR, включая McDonalds, KFC, Hungry Jacks и т. Д.), Поставляя оборудование и программное обеспечение для киосков самообслуживания. Вот фото с их сайта:
Пока все хорошо, никаких проблем. Они работают в основном с Java, которая не является одним из моих основных языков, но мне удалось сделать все, что они просили меня, и теперь я могу часто работать с NodeJS, что больше моей области. Несколько хлопотной, но увлекательной частью работы был AWS. Компания в значительной степени полностью зависит от Amazon Web Services, все наши ресурсы компьютерного зрения находятся на AWS, все конфигурации киосков и развертывания продуктов находятся на AWS, наши внутренние инструменты зависят от AWS. Практически вся компания работает на AWS (за приличную ежемесячную плату).
Я не был уверен, насколько хорошо я справлюсь со стороной AWS, будучи моей первой большой технической работой и имея небольшой опыт работы с такими инструментами. Раньше я занимался фрилансом, кое-где побочных концертов и программировал с юных лет около 10 лет, но никогда в таком большом масштабе.
К моему удивлению, в большинстве случаев работать с AWS было очень легко и просто. Я получил почти все, что мне нужно было сделать очень быстро. Что касается развертывания, я просто следил за документацией компании с некоторыми подсказками от старших разработчиков, таких как журналы в CloudWatch, базы данных в RDS, хранилища на S3, у меня был период обучения, но все шло хорошо с самого начала.
Вот что хорошего в AWS. Все просто. Как правило, с помощью нескольких щелчков мышью вы запускаете новую услугу, и вы можете очень легко начать кодирование с использованием этого ресурса.
И вот где я вам лгу. «Все просто». Конечно ... если все, что вам нужно сделать, это заставить работать автономную лямбду. Если у вас нет проблем с безопасностью и нет необходимости в сети. Как только вы начинаете думать о VPC, подсетях, конечных точках служб, аутентификации шлюза API, все очень быстро идет по нисходящей спирали.
Но не волнуйтесь, я просто бросил несколько громких слов тут и там для драматического эффекта. В большинстве случаев эти вещи вас не беспокоят, но когда они возникают, разобраться с ними может быть довольно сложно. Приведу вам пример.
Мы создаем новую онлайн-панель для управления всеми этими киосками самообслуживания, и AWS является основой всего этого. Мы говорим о входе в систему Cognito и аутентификации API, бессерверных лямбдах, темах IoT и триггерах SQS, базах данных RDS и всем пакете. Это, безусловно, стало для меня большим опытом в области разработки программного обеспечения, сервисов AWS и, что несколько удивительно, отладки.
Я должен сказать. Если что-то пойдет не так в AWS, вы либо обнаружите проблему в течение 5 минут, либо полностью запутаетесь. Одна большая проблема, с которой мы столкнулись, заключалась в том, что наши лямбды находились внутри VPC. По соображениям безопасности мы хотели закрыть нашу базу данных RDS в белом списке IP, вместо того, чтобы оставлять ее открытой для 0.0.0.0/0 (любые соединения). Итак, ответ заключался в том, чтобы поместить наши лямбды внутри VPC, чтобы мы могли приписать им IP-адрес и группу безопасности, которые могут быть внесены в белый список RDS. Все идет нормально. Все сработало.
Потом мы столкнулись с некоторыми проблемами. Как только лямбды оказались в VPC, все перестало работать. Когда мы удалили конфиги VPC, лямбды ожили. Мы проделали около 50 различных действий в конфигурации VPC, чтобы заставить ее работать, и она просто не работала.
Поэтому мы решили отобразить весь процесс. Мы создали новый тест Lambda и сделали самое простое из возможных. Написал «Hello World» и поместил его в VPC. Успех. Работающий. Затем мы написали простейший возможный код для извлечения данных из базы данных RDS и снова опубликовали Lambda в VPC. К нашему удивлению… это сработало. Таким образом, проблема заключалась не в RDS и VPC, который не попал в белый список, или VPC, не имеющем внешнего доступа в Интернет, как мы думали. Альтернатив было не так уж и много. Затем я сделал следующий шаг в процессе, который извлек информацию о базе данных из нашего AWS Secrets Manager вместо того, чтобы вручную настраивать соединение. Та-Да! Функция больше не работала. Нашли проблему, но почему?
Оказывается, есть много сервисов, которые по умолчанию недоступны из VPC. И Secrets Manager - один из них. Решение состоит в том, чтобы перейти к настройкам VPC и добавить конечную точку службы для нужной службы. В моем случае Secrets Manager. После этого все функции внутри VPC ожили.
Я столкнулся с подобными проблемами с тремя другими сервисами. SQS, Cognito и Интернет вещей. Проблема с SQS такая же, как и с менеджером секретов. Я использовал SQS в качестве триггера для лямбды, но эта лямбда не вызывалась после того, как SQS получил сообщение. Проблема снова была в VPC. Теперь Cognito и IoT стали немного другими. Обе эти службы отлично работают в VPC. Я использую Cognito в качестве аутентификатора API для всех VPC Lambdas, и это не проблема, но как только я использую AWS-SDK для Cognito, например, для перечисления всех пользователей в пользовательском пуле, внутри VPC происходит сбой. То же самое касается IoT, который не публикует сообщения MQTT в IoT, если они находятся внутри VPC. Это произойдет, если я использую IoT-SDK, но если я использую для этого функцию из AWS-SDK, это не сработает. У меня нет решения проблемы SDK, но мне не нужно, чтобы он был в VPC, поэтому я просто полностью удалил VPC из этих лямбда-выражений, но об этом нужно знать.
Я надеюсь, что вы кое-что узнали из этой статьи, но что я действительно хочу подчеркнуть, так это важность повторения и повторения попыток, а также умение выполнять отладку. Пару раз, если бы я лучше выполнял отладку, я бы потратил, может быть, два часа вместо двух дней на решение проблемы, и, как нам всегда говорят, время - деньги. Кроме того, как бы страшно это ни выглядело, как это было в моем случае с Java и AWS, иногда вам просто нужно сначала окунуться в голову, потому что вы точно не научитесь, если не попробуете. Чтобы попасть в трудную ситуацию, нужно мужество, но зачастую результат стоит риска.
