Михаил Потапенков, нет. насколько я знаю.
Варианта ровно три:
1. program files (установка для всех пользователей)
2. user profile (установка для одноого пользователя)
3. портативная версия, подготовленная другими товарищами. Я, как правило, предпочитаю софт от производителя и не запакованный какими-то другими чуваками(паранойи мало не бывает) поэтому советовать вам его не буду. Но вы можете попробовать. :D
Все остальное - это игрища с этими тремя способами
Иван Шумов, вхождение в управление инфраструктурой с помощью CF сильно сложнее чем в TF, поскольку CF в том числе следит за состоянием инфраструктуры (о чем надо помнить и дебажить если что-то не получается), и до сих пор обладает меньшими возможностями по интерполяции чем активно развивающийся TF.
Мнение, конечно, у каждого может быть свое, но организовать полноценную инфраструктуру "под ключ" в TF сильно легче чем в CF (именно поэтому TF получил такую популярность в свое время)
А про terraform - есть несколько кейсов когда нужно запускать CF стек из TF модулей в работе, так что "запустить скрипт" и "запустить CF" в данном случае равнозначны =)
добавлю еще из неожиданных идей:
используйте cloudformation (можно даже внутри terraform,ага :D )
в CF AWS предоставляет отличные инструменты для контроля практически любой ситуации.
Например в вашем случае можно организовать nested stacks - в первом стеке создается и провижинится инстанс, с минимально необходимыми достуами в сеть, во втором - настраиваются SG и NACL
Второй стек может быть запущен только после полностью успешного завершения первого стека - вы даже можете написать тесты на приложение прямо в CF и только по их успешному прохождению послать cfn-signal в CF, чт можно продолжать провижининг и открывать порты в NACL\SG в следующем стеке.
Одно но: порог вхождения в CF сильно выше чем у TF и это не просто инструмент а сервис, со своим контролем и хранением состояния и всеми причитающимися, что является и плюсом(для работоспособности) и минусом(для обновлений, контроля и, конечно, вхождения в управление CF стеками)
EkaterinaKh, мне кажется, это все таки не ваш случай.
В этом вопросе утерян доступ к аккаунту в принципе. Судя по вашему вопросу, на который уже ответил Иван Шумов - у вас утеряны только ключи доступа к конкретной машине - инстанс что-то требует. Как правило,
в описанной вами ситуации, требуется ключ безопасности, который создал тот, кто запускал инстанс - AWS над ним не властен. Совсем. Может только расшифровать зашифрованное этим ключом, но самого ключа у AWS нет.
Работы вам необходимы исключительно технические, судя по вашему описанию. В этом вопросе обсуждалось возвращения доступа к аккаунту в принципе - автор вообще не мог ничего делать в AWS
Вам необходим человек с опытом использования AWS чтобы провести некоторое количество работ по организации доступа к коду. Если они возможны - все зависит от квалификации того, кто настраивал.
Опят же, если судить по вопросу, который задали в, ясно видно (и никто вас в этом не упрекает) что знаний о том как организован AWS и что там нужно делать у вас недостаточно. Просто поищите того кто разбирается.
mozas, к сожалению в 7-ке отсутствуют соответствующие коммандлеты. Может быть их можно установить с помощью windows management framework 5.x но далеко не все из того что есть в 10-ке появится в предыдущих версиях ОС
Однако что вам мешает просто автоматизировать те ручные действия которые вы делаете: выяснение параметров подключения,затем запуск команды добавления роута
не очень красиво, зато позволит вам работать не отвлекаясь на эту проблему.
Немного не понимаю как этот комментарий соотносится с изначальной постановкой вопроса =)
appdynamics - application monitoring
Zabbix - нет. Технически можно много чего наваять и с использованием zabbix то APM в нем, насколько я знаю, отсутствует.
Касательно вопроса изначального: заббикс, как правило, снимает метрики с известного эндпойнта.
Если приложение предоставляет такой эндпойнт или умеет само слать метрики в удаленную систему - то разделение контейнеров выглядит более чем логичным.
Если для снятия метрик с приложения через JMX есть Java API Gateway https://www.zabbix.com/documentation/current/ru/ma...
В случае описанном в статье на zabbix.com тоже достаточно пробросить JMX порт в локалхост
Если вы планируете работать с докер - меняйте ваше представление о том, как все должно работать.
процесс = контейнер.
процесс падает = падает контейнер, докер демон его перезапускает.
заббикс(тоже контейнер) мониторит докер и репортит о перезапуске контейнера
Если надо заббиксом снимать с основного процесса какие то метрики - порт откуда запрашивать метрики выставляется из контейнера на хост
Если процесс пушит метрики в заббикс - так еще проще, выставляем заббиксовый эндпойнт на хост
Если не строить внутри контейнера связку сервисов - ваша жизнь будет сильно легче. Конфигурация приложения не должна зависеть от конфигурации мониторинга этого приложения, а вы именно это пытаетесь построить.
Однако же,иногда есть потребность в таком запуске(несколько процессов внутри контейнера).
Крайне рекомендую вам почитать официальную документацию как это делать https://docs.docker.com/config/containers/multi-se...
Urbansamurai многие клауд вендоры имеют решения совместимые с S3 API. Это не значит что они работают точно так же как и AWS S3, особенности реализации могут играть важную роль.
добавлю еще: Если не получается разобраться, то вот вам статья хабраюзера zhovner в помощь
Мы в похожей конфигурации живем достаточно долго - с 2016 года и все работает как часы, правда используем eap-radius в интеграции с MS AD
Иван Шумов, не хочу с вами спорить, вы слишком категоричны.
Продукт жив и здравствует, нас вполне себе аффектили эти самые падения, но не аффектили наших клиентов.
и PhD на подписке шлет новости, так что :D
Иван, все зависит от того, как построено приложение.
Случаев падения региона полностью еще не было - падение одной AZ нам не страшно.
Регион был выбран по близости клиентам =)
Вообще (я, кстати, ни разу не девелопер, чтобы если вдруг что сослаться "у одного моего друга, не у меня, есть опыт работы с индексами в S3) в случае необходимости БД-подобных операций AWS всегда предлагал использовать БД в дополнение к S3
Например, хранить индекс в динамо (даже лямбдочки по автозаполнению динамы где то в доках AWS есть) - и уже с индексом работать батчами, следующей операцией читая предложенные объекты.
Однако же, динамо ограничен 100 объектами в батчах и размером выдаваемых объектов, так что и тут не все так однозначно.
Что, впрочем не мешает использовать какую нибудь другую БД вместо динамы
2. chef, ansible - да любой.
То, что терраформ может, скажем, темплейтировать файлы - не означает что он должен это делать всегда и везде. Тем более что делает он это плохо, а любой дополнительный ресурс - это вероятность зависимости которая тригернет пересоздание других ресурсов.
1. каждый логический слой - это отдельная папка с файлами терраформа. Терраформ всегда применяет все файлы лежащие в папке, если вы не задали таргет ключ в командной строке
Например, логический слой - элементы VPC(подсети, route tables, dhcp options и т.п.)
Логический слой - один сервис вашего приложения
Логический слой - все инфраструктурные сервисы, запускаемые с помощью нормально написанных модулей.
Здесь все обсуждаемо, поскольку если за activemq+rabbitmq отвечает одна команда - она может не задевая других делать применение изменений в своем слое.
Если это разные команды - возможно имеет смысл разнести, чтобы изменения одной команды не аффектили сервис другой команды.
Здесь нужно подходить логично и, впоследствие, итеративно решать проблемы возникающие из-за того распределения которое вы организовали.
Например, изначально мы запихали все инфраструктурные сервисы в один слой, но, все они были написаны в модулях и применялись через -target. В принципе, было норм.
Например, terraform apply -target='module.activemq' применял изменения только AMQ, даже если были реальные изменения в соседних rabbitmq, couchbase и т.п. модулях в этом же слое.
Впоследствие, мы неоднократно перераспределяли все сервисы по другим слоям, согласно зоне ответственности команд которые за них отвечают (например если rabbit уехал в другую команду из той, в которой он был изначально)
Отдельно хочется отметить, что большую попаболь в объединении сервисов в слоях доставляет корректность написанных модулей сервисов( напомню, что модули нужны, чтобы ваш препрод и прод запускались из одного кода и инфра изменения тестировались не на проде). Например, в нашем случае, один или два сервиса пересоздавались каждый раз, когда делался терраформ apply несмотря на то, что реальных изменений ни в сервисах ни в параметрах их не было - и приходилось постоянно таргетироваться на изменяемый сервис вместо того чтобы просто делать terraform apply в репозитории (валидация получившегося плана была просто адовой - куча изменений не имеющих отношения к тому, что реально должно поменяться). В нашем случае причиной было использование вполне определенных ресурсов терраформ, которые пересоздаются всегда. Например template_dir или local_file.
Приходится искать способы чтобы их не использовать.
Варианта ровно три:
1. program files (установка для всех пользователей)
2. user profile (установка для одноого пользователя)
3. портативная версия, подготовленная другими товарищами. Я, как правило, предпочитаю софт от производителя и не запакованный какими-то другими чуваками(паранойи мало не бывает) поэтому советовать вам его не буду. Но вы можете попробовать. :D
Все остальное - это игрища с этими тремя способами