Использую Swagger/OpenAPI при разработке backend на Java. Использую подход API First. Что для себя усвоил. При описании paths
использую теги, чтоб методы были сгенерированы в правильные интерфейсы
всегда указываю operationId, чтоб был верно смапирован метод контроллера при имплементации
всегда описываю request/response схему, чтоб были сгенерированы DTOшки
при описании компонентов не использую точки и различные не стандартные знаки, иначе могут быть проблемы в сгенерированом коде. Например вы оперируете названием File.Response.SuccessDownloadFile , я бы использовал название FileDownloadSuccessResponse
в Java я получаю на выходе сгенерированные DTOшки и интерфейсы endpointов с дефаултной имплементацией return new ResponseEntity<>(HttpStatus.NOT_IMPLEMENTED);
ну в принципе и всё. Т.е. для корректной работы реалезую имплементацию endpointов (методов) интерфейсов и DTOшки через мапперы далее использую модель данных в программе.
Далее в статье упоминаете о технологическом долге, что надо что-то там обновлять на нескольких сервисах. Тут думаю есть немного недопонимание. Swagger в данной ситуации является API контрактом (Interface Agreement), и у него есть версионость. Так вот, вы этим самым говорите, что такая-то версия вашего приложения общается вот таким-то языком и обозначаете версию вашего swaggera. Другие приложения, которые с вами общаются, должны поддерживать понятный вашему приложению язык общения, т.е. должны присылать запросы в соответствии API контрактом, но и ответ им будет понятен. Но если вы вносите правки в swagger, вы по сути делаете новую версию, меняете язык общения с вашим приложением, и другие должны у себя внести этим самые правки. т.е. это не является технологическим долгом, я этим вы наводите порядок и исключаете непонятные несогласованности в общении приложений между собой. Необходимо в идеале обеспечить обратную совместимость API. Чтоб при его обновлении не нужно было сразу везде всё менять. Тут уже вступает логика семантической версионности.
У человека написавшего эту статью явно нету понимания для чего DevOps вообще нужен и как строятся CI/CD процессы. Другое дело опыт компаний, в которые приходят типа DevOps инженеры окончившие быстрые курсы и приносят свои костыли, тогда получается не разворотливый франкинштейн.
Похвала за проведённое исследование. Хотелось бы внести пару ясностей. В статье заявлен Spring Framework, но статья описывает исследование Spring Boot Framework, что является некой обёрткой для Спринга. Принцип один, но построение контекста отличается. Ну и в статье я бы сказал, что скорее описано построение контекста. Далее заявляется внедрение кастомной логики в жизнный цикл, это сама по себе плохая затея, правильнее было бы задуматься как решить поставленную задачу в рамках возможности стандартных методов и подходов фреймворка, т.к. дальнейшее обновление может сломать вашу программу. Также другой программист, который столкнётся с вашей кастомной логикой может очень долго плеваться и не понимать, что происходит. В принципе фреймворки для этого и придуманы, чтоб ускорить и упорядочить разработку типовых задач. Для лучшего понимания особенно для новичков было бы не плохо описать поведение Сервисов, Контроллеров, Репозиториев, Использование Хибернейт, Использование больше, чем одной DB одновременно, как себя ведут Транзакции, Прокси объекты, Аспекты и т.д. поле не паханное ;-)
Поддерживаю. У автора видимо подразумевается небольшое приложение с зашитыми в код возможными ролями. Но сама изначальная идея про роли подразумевает назначение любых ролей на отдельные сегменты приложения, для доступа к которым пользователь должен содержать указанные роли исходя от бизнес задачи, т.е. должна быть разделена бизнес логика и техническая реализация, а в статье оно смешано.
Познавательно для желающих реализовать репликацию данных. Сам писал собственный тул для реплицирования из SQLServer в PostgreSQL и Kafka на основе вычитывания данных из SQLServer Snapshot и последующим автоматическим переключением на живую SQLServer базу и считыванием изменений из CDC (LSN является ориентиром). Очень много подводных камней. Сейчас улучшаю перформанс первоначальной загрузки из snapshot и тесты показывают, что в разы вырастает скорость если считываю данные из snapshot в CSV, после через CopyIn в PostgreSQL с временным удалением индексов и primary ключей в PostgreSQL.
ещё вопрос. допустим я делаю 3-4 разные pipeline, которые в репозитории реагируют на изменения в репозитории на определённые папки или файлы. как в gitlab реализовать подобный триггер, чтоб в зависимости от тригера срабатывали разные pipeline?
либо вариант, когда pipeline проверяет код на его соберабельность , но при этом ничего никуда не деплоит и срабатывает на любых ветках, кроме основной. т.е. по факту на фючер ветках. Но не нерагирует, если изменили просто README.md
За наводку по поводу resource_group благодарю, посмотрю.
В остальном я возможно не достаточно смог объяснить в чём трудность. Тестирование через docker так себе затея, для этого описываются шаги в CI/CD. Живой пример. Допустим у нас есть приложение на Java (Spring Boot + Maven). Для того , чтобы нам собрать приложение мы должны запустить команду
mvn clean compile package
Maven тянет зависимости, компилирует код и запускает unit тесты, после собирает готовый jar, а после уже собираем образ и ложем его в registry. В юнит тестах используется test containers для запуска postgresql, и стартует оно в docker контейнере, отпрабатывает тестовые сценарии и всё гасит за собой.
Если Gitlab Runner запущен в своём контейнере, что в принципе логично, то получаем ситуацию docker in docker. Если мы в докер пробрасываем socket, чтоб всё сработало как надо, то получаем конфликтную ситуацию, когда одновременно отрабатываются две pipeline с тестовыми сценариями. Из этого и возникает вопрос, а как правильно использовать Gitlab Runnerы ?
Далее про docker container registry. Из личного опыта, это как минимум удобно и по моему мнению правильно. Вы можете разворачивать всю инфраструктуру через IaC и можете управлять версиями приложения в любом отрезке времени, в любом окружении.
Я ни в коем случае не осуждаю ваш подход через артефакты, но вижу в нём недостаток. Получается, что вы докер образ, который запускаете создаёте на лету, размещая в него содержимое вашего артефакта т.е. какую-то определённую версию вашей программы. Нюанс в том, что ваше окружение, оно другое, отличное от того, в котором вы тестировали и могут возникнуть нюансы.
Живой пример из опыта. Java приложение, которое через JDBC общается с Microsoft SQLServer (не самой свежей версии, изза определённых причин заказчик не мог себе позволить upgrade). Java приложение было написано на java8. Всё отлично работает. Спустя какое-то время, ничего не меняли, собираем docker образ, а приложение уже не работает. Почему? А потому-что приехало обновление java 8, где было по-умолчанию отключен TLS 1.1, и всё, приложение с базой уже общаться не смогло. Образ из docker container registry, продолжал работать, т.к. его состояние осталось не изменным.
А есть смысл публиковать образы в docker registry? Почему бы сразу не деплоить на стенд?
Конечно! Суть тестов, что вы тестируете определённую версию приложения и если всё ок, отправляете в продакшен. А если не использовать docker container registry, то получается для теста собирается образ и при деплои на ПРОД также собирается образ. И тут может произойти не хорошая ситуация, что ваши образы могут отличаться. Вышли какие-то обновления зависимостей и т.д. и т.п. и может оказаться, что в тестах всё хорошо, а в продакшене не работает. В этом то и вся суть тестирования, что протестировали, то в продакшен и отправили. т.е. собрали образ, повесили на него тег версии и запушили в registry. Из реестра взяли, запустили в тестовом окружении, всё гут, тот-же докер образ деплоится в продакшен.
Не очень понимаю как pipeline могут мешать друг другу...
Предположим у нас есть репозитории
serviceA - одно приложение
serviceB - второе приложение
serviceApp - некий репозиторий с предписанием деплоймента
мы коммитнули изменения в serviceA и serviceB и ждём их сборки, чтоб через serviceApp потом их задеплоить на DEV и TEST окружение. и на обеих репозиториях serviceA и serviceB запустились pipelines. В рамках unit тестов запускаются тестовые контейнеры например с postgresql, kafka, ещё что-то. и если эти pipeline будут работать в одном и том-же окружении, то потенциально возникнет конфликт интересов, что обеим pipeline надо будет запустить одинаковые образы и возможно может остаться мусор в виде непогашенного docker контейнера, запущеного для тестов, например с kafka. Хотелось бы получить для каждой pipeline изолированное окружение, чтоб они не могли друг другу помешать. чтоб допустим могло спокойно одновременно отработаться 5 различных pipeline. по сути логика docker in docker.
У вас runner запускаются в docker? Или без docker в самой ОС (в шеле)?
Ситуация следующая. У нас в компании работаем в Azure, и там с CI/CD всё чётко, проблем особо нету, используются Microsoft агенты. Каждый запуск pipeline в изолированном окружении. В общем всё как требуется.
GitLab я установил для себя, на своём сервере, для своих личных проектов. GitLab Runner пока не настраивал, пытаюсь разобраться как правильнее сделать. CI/CD в гитлабе отличается от того, как это решено в Azure. плодить виртуалки для обеспечения изоляции среды для pipeline мне кажется немного странным. Использование докера более правильный подход, но вот каким образом реализовать, т.к. если замапить docker socket в контейнер, это в принципе не безопасно и приведёт к конфликтами при параллельном запуске pipeline.
В данный момент пытаюсь разобраться как правильно настроить и использовать gitlab-runnerы для сборки docker образов, публикации их в registry, и последующий деплой на DEV, TEST, PROD. Интересует у кого есть реальный опыт как делать не надо и как по вашему мнению правильнее ? хотелось бы получить изоляцию, чтоб могли одновременно отработаться несколько pipeline и друг другу не мешали, и после завершения pipeline, чтоб не осталось мусора (в том числе и docker контейнеры, которые могли стартануть для интеграционых тестов)
если мы говорим о защите JWT токеном с тем, что CDN так-же проверяет его срок действия и подпись, то я не могу себе даже представить сценарий, при котором вы его сможете подделать или обойти без наличия приватного ключа, которым он подписывается.
Вполне рабочее решение. Возможно только имеет смысл не в README проверять, а достаточно в репозитории github держать некий служебный файл, например manifest.json и в нём и версия, и дата, и контрольная сумма и ссылка на бинарник, и ещё что-то, что ваша программа на Си должна знать.
А вообще мир давно уже движется в направлении web и мобильных устройств. Если весь функционал, который планируете реализовать, можно засунуть в web, то это было бы возможно лучшим решением. Платформенная независимость, клиент всегда работает с самой актуальной версией, если коммерческое продакшн решение, то можно организовать платную подписку на фичи допустим какие-то. Предоставить API для интеграции в какие-то другие ПО и т.д. фантазировать можно много.
Если я правильно понял, то представленная в статье Админка по сути является проксёй для docker container registry, которая обеспечивает безопасность репозитория (user management) и Web GUI
если вы не являетесь владельцем домена, то риски есть всегда.
В предыдущем комментарии вы написали, что сети это для вас новое. То возможно вам сначала нужно в образовательных целях попробовать что-то сделать, допустим даже на каком-то бесплатном хостинге, если не готовы оплатить VPS/VDS. По упрожняться, понять что и как работает и определиться, что вы хотите, а после уже приобрести себе домен, арендовать виртуалку, и реализовать свои пожелания
Статья немного странная. Описаны нюансы YAML о которых стоит знать, но сходу определить, что этот формат плох, от автора весьма странно. Всё зависит от задачи. YAML с приходом DevOps стал очень популярен, и для этого есть причины. Для человека, который пишет конфигурации YAML оказался более читабелен и удобен, чем JSON. Так-же при diff в YAML будет видно явное различие, у JSON, только если он написан с pretty форматированием, с соблюдением whitespace. у YAML этой проблемы нету, т.к. структура файла изначально определена стандартом. JSON типизирован и предсказуем, у YAML есть нюансы. Всё зависит от задачи и реализации парсера/врайтера. Приложение, которое считывает конфигурацию из YAML рассчитывает на определённую модель данных, которые может конфигурационный yaml содержать, по этому особых проблем с использованием YAML я не вижу. Нюансы, которые могут возникнуть либо вы о них быстро узнаете, когда увидите, что конфигурация себя ведёт не правильно, но скорее всего с большинством описанных проблем вы даже и не столкнётесь.
Всё зависит от ваших задач. Но вы должны осознавать одну вещь. Если вы распространяете ПО, которое должно обновляться. Но вы в него в жёсткую пропишите IP адрес с обновлениями, может приключиться не хорошая ситуация, когда у вас по какой-либо причине сменится IP. Провайдер его вам принудительно изменит, вы смените провайдеры, то ваше ПО уже за обновлениями не достучится. И клиента просить или заставлять менять какой-то IP, где-то в конфигурации или ещё что-то, так себе задачка. Тут имеет смысл в ПО прописывать имя хоста вашего домена/поддомена и через DNS иметь возможность менять IP, по которому ваше ПО будет обращаться. Для этих целей можно либо на домашнем ПК держать Web сервер, с которого будут идти обновления, или лучше всего оплатить VDS/VPS (это не дорого) и там развернуть систему обновлений вашей программы.
Использую Swagger/OpenAPI при разработке backend на Java. Использую подход API First. Что для себя усвоил. При описании paths
использую теги, чтоб методы были сгенерированы в правильные интерфейсы
всегда указываю operationId, чтоб был верно смапирован метод контроллера при имплементации
всегда описываю request/response схему, чтоб были сгенерированы DTOшки
при описании компонентов не использую точки и различные не стандартные знаки, иначе могут быть проблемы в сгенерированом коде. Например вы оперируете названием File.Response.SuccessDownloadFile , я бы использовал название FileDownloadSuccessResponse
в Java я получаю на выходе сгенерированные DTOшки и интерфейсы endpointов с дефаултной имплементацией
return new ResponseEntity<>(HttpStatus.NOT_IMPLEMENTED);ну в принципе и всё. Т.е. для корректной работы реалезую имплементацию endpointов (методов) интерфейсов и DTOшки через мапперы далее использую модель данных в программе.
Далее в статье упоминаете о технологическом долге, что надо что-то там обновлять на нескольких сервисах. Тут думаю есть немного недопонимание. Swagger в данной ситуации является API контрактом (Interface Agreement), и у него есть версионость. Так вот, вы этим самым говорите, что такая-то версия вашего приложения общается вот таким-то языком и обозначаете версию вашего swaggera. Другие приложения, которые с вами общаются, должны поддерживать понятный вашему приложению язык общения, т.е. должны присылать запросы в соответствии API контрактом, но и ответ им будет понятен. Но если вы вносите правки в swagger, вы по сути делаете новую версию, меняете язык общения с вашим приложением, и другие должны у себя внести этим самые правки. т.е. это не является технологическим долгом, я этим вы наводите порядок и исключаете непонятные несогласованности в общении приложений между собой. Необходимо в идеале обеспечить обратную совместимость API. Чтоб при его обновлении не нужно было сразу везде всё менять. Тут уже вступает логика семантической версионности.
У человека написавшего эту статью явно нету понимания для чего DevOps вообще нужен и как строятся CI/CD процессы. Другое дело опыт компаний, в которые приходят типа DevOps инженеры окончившие быстрые курсы и приносят свои костыли, тогда получается не разворотливый франкинштейн.
Похвала за проведённое исследование. Хотелось бы внести пару ясностей. В статье заявлен Spring Framework, но статья описывает исследование Spring Boot Framework, что является некой обёрткой для Спринга. Принцип один, но построение контекста отличается. Ну и в статье я бы сказал, что скорее описано построение контекста. Далее заявляется внедрение кастомной логики в жизнный цикл, это сама по себе плохая затея, правильнее было бы задуматься как решить поставленную задачу в рамках возможности стандартных методов и подходов фреймворка, т.к. дальнейшее обновление может сломать вашу программу. Также другой программист, который столкнётся с вашей кастомной логикой может очень долго плеваться и не понимать, что происходит. В принципе фреймворки для этого и придуманы, чтоб ускорить и упорядочить разработку типовых задач. Для лучшего понимания особенно для новичков было бы не плохо описать поведение Сервисов, Контроллеров, Репозиториев, Использование Хибернейт, Использование больше, чем одной DB одновременно, как себя ведут Транзакции, Прокси объекты, Аспекты и т.д. поле не паханное ;-)
Поддерживаю.
У автора видимо подразумевается небольшое приложение с зашитыми в код возможными ролями.
Но сама изначальная идея про роли подразумевает назначение любых ролей на отдельные сегменты приложения, для доступа к которым пользователь должен содержать указанные роли исходя от бизнес задачи, т.е. должна быть разделена бизнес логика и техническая реализация, а в статье оно смешано.
Познавательно для желающих реализовать репликацию данных. Сам писал собственный тул для реплицирования из SQLServer в PostgreSQL и Kafka на основе вычитывания данных из SQLServer Snapshot и последующим автоматическим переключением на живую SQLServer базу и считыванием изменений из CDC (LSN является ориентиром). Очень много подводных камней. Сейчас улучшаю перформанс первоначальной загрузки из snapshot и тесты показывают, что в разы вырастает скорость если считываю данные из snapshot в CSV, после через CopyIn в PostgreSQL с временным удалением индексов и primary ключей в PostgreSQL.
Чем не устроил S3 или ему подобный Minio? или подобные fileshare?
Поддерживаю. Calico и Cilium на сегодняшний день самые топовые на сколько мне известно.
ещё вопрос. допустим я делаю 3-4 разные pipeline, которые в репозитории реагируют на изменения в репозитории на определённые папки или файлы. как в gitlab реализовать подобный триггер, чтоб в зависимости от тригера срабатывали разные pipeline?
либо такой вариант
либо вариант, когда pipeline проверяет код на его соберабельность , но при этом ничего никуда не деплоит и срабатывает на любых ветках, кроме основной. т.е. по факту на фючер ветках. Но не нерагирует, если изменили просто README.md
За наводку по поводу resource_group благодарю, посмотрю.
В остальном я возможно не достаточно смог объяснить в чём трудность. Тестирование через docker так себе затея, для этого описываются шаги в CI/CD. Живой пример. Допустим у нас есть приложение на Java (Spring Boot + Maven). Для того , чтобы нам собрать приложение мы должны запустить команду
Maven тянет зависимости, компилирует код и запускает unit тесты, после собирает готовый jar, а после уже собираем образ и ложем его в registry. В юнит тестах используется test containers для запуска postgresql, и стартует оно в docker контейнере, отпрабатывает тестовые сценарии и всё гасит за собой.
Если Gitlab Runner запущен в своём контейнере, что в принципе логично, то получаем ситуацию docker in docker. Если мы в докер пробрасываем socket, чтоб всё сработало как надо, то получаем конфликтную ситуацию, когда одновременно отрабатываются две pipeline с тестовыми сценариями. Из этого и возникает вопрос, а как правильно использовать Gitlab Runnerы ?
Далее про docker container registry. Из личного опыта, это как минимум удобно и по моему мнению правильно. Вы можете разворачивать всю инфраструктуру через IaC и можете управлять версиями приложения в любом отрезке времени, в любом окружении.
Я ни в коем случае не осуждаю ваш подход через артефакты, но вижу в нём недостаток. Получается, что вы докер образ, который запускаете создаёте на лету, размещая в него содержимое вашего артефакта т.е. какую-то определённую версию вашей программы. Нюанс в том, что ваше окружение, оно другое, отличное от того, в котором вы тестировали и могут возникнуть нюансы.
Живой пример из опыта. Java приложение, которое через JDBC общается с Microsoft SQLServer (не самой свежей версии, изза определённых причин заказчик не мог себе позволить upgrade). Java приложение было написано на java8. Всё отлично работает. Спустя какое-то время, ничего не меняли, собираем docker образ, а приложение уже не работает. Почему? А потому-что приехало обновление java 8, где было по-умолчанию отключен TLS 1.1, и всё, приложение с базой уже общаться не смогло. Образ из docker container registry, продолжал работать, т.к. его состояние осталось не изменным.
Конечно! Суть тестов, что вы тестируете определённую версию приложения и если всё ок, отправляете в продакшен. А если не использовать docker container registry, то получается для теста собирается образ и при деплои на ПРОД также собирается образ. И тут может произойти не хорошая ситуация, что ваши образы могут отличаться. Вышли какие-то обновления зависимостей и т.д. и т.п. и может оказаться, что в тестах всё хорошо, а в продакшене не работает. В этом то и вся суть тестирования, что протестировали, то в продакшен и отправили. т.е. собрали образ, повесили на него тег версии и запушили в registry. Из реестра взяли, запустили в тестовом окружении, всё гут, тот-же докер образ деплоится в продакшен.
Предположим у нас есть репозитории
serviceA - одно приложение
serviceB - второе приложение
serviceApp - некий репозиторий с предписанием деплоймента
мы коммитнули изменения в serviceA и serviceB и ждём их сборки, чтоб через serviceApp потом их задеплоить на DEV и TEST окружение. и на обеих репозиториях serviceA и serviceB запустились pipelines. В рамках unit тестов запускаются тестовые контейнеры например с postgresql, kafka, ещё что-то. и если эти pipeline будут работать в одном и том-же окружении, то потенциально возникнет конфликт интересов, что обеим pipeline надо будет запустить одинаковые образы и возможно может остаться мусор в виде непогашенного docker контейнера, запущеного для тестов, например с kafka.
Хотелось бы получить для каждой pipeline изолированное окружение, чтоб они не могли друг другу помешать. чтоб допустим могло спокойно одновременно отработаться 5 различных pipeline. по сути логика docker in docker.
Ситуация следующая. У нас в компании работаем в Azure, и там с CI/CD всё чётко, проблем особо нету, используются Microsoft агенты. Каждый запуск pipeline в изолированном окружении. В общем всё как требуется.
GitLab я установил для себя, на своём сервере, для своих личных проектов. GitLab Runner пока не настраивал, пытаюсь разобраться как правильнее сделать. CI/CD в гитлабе отличается от того, как это решено в Azure. плодить виртуалки для обеспечения изоляции среды для pipeline мне кажется немного странным. Использование докера более правильный подход, но вот каким образом реализовать, т.к. если замапить docker socket в контейнер, это в принципе не безопасно и приведёт к конфликтами при параллельном запуске pipeline.
В данный момент пытаюсь разобраться как правильно настроить и использовать gitlab-runnerы для сборки docker образов, публикации их в registry, и последующий деплой на DEV, TEST, PROD. Интересует у кого есть реальный опыт как делать не надо и как по вашему мнению правильнее ? хотелось бы получить изоляцию, чтоб могли одновременно отработаться несколько pipeline и друг другу не мешали, и после завершения pipeline, чтоб не осталось мусора (в том числе и docker контейнеры, которые могли стартануть для интеграционых тестов)
Принято. Отличное решение. С токеном можно прикрутить любой способ авторизации. OAuth, LDAP, Username/Password и т.д.
Поставил бы плюсик, но к сожалению пока статус не позволяет этого делать.
если мы говорим о защите JWT токеном с тем, что CDN так-же проверяет его срок действия и подпись, то я не могу себе даже представить сценарий, при котором вы его сможете подделать или обойти без наличия приватного ключа, которым он подписывается.
Вполне рабочее решение. Возможно только имеет смысл не в README проверять, а достаточно в репозитории github держать некий служебный файл, например manifest.json и в нём и версия, и дата, и контрольная сумма и ссылка на бинарник, и ещё что-то, что ваша программа на Си должна знать.
А вообще мир давно уже движется в направлении web и мобильных устройств. Если весь функционал, который планируете реализовать, можно засунуть в web, то это было бы возможно лучшим решением. Платформенная независимость, клиент всегда работает с самой актуальной версией, если коммерческое продакшн решение, то можно организовать платную подписку на фичи допустим какие-то. Предоставить API для интеграции в какие-то другие ПО и т.д. фантазировать можно много.
Если я правильно понял, то представленная в статье Админка по сути является проксёй для docker container registry, которая обеспечивает безопасность репозитория (user management) и Web GUI
как вариант github
вы попробуйте более конкретно описать свою потребность. Что за ПО ? на чём написано/или пишете? какую задачу решает? и т.д.
если вы не являетесь владельцем домена, то риски есть всегда.
В предыдущем комментарии вы написали, что сети это для вас новое. То возможно вам сначала нужно в образовательных целях попробовать что-то сделать, допустим даже на каком-то бесплатном хостинге, если не готовы оплатить VPS/VDS. По упрожняться, понять что и как работает и определиться, что вы хотите, а после уже приобрести себе домен, арендовать виртуалку, и реализовать свои пожелания
ну если за домен исправно платить, то поменяться не может.
Статья немного странная. Описаны нюансы YAML о которых стоит знать, но сходу определить, что этот формат плох, от автора весьма странно. Всё зависит от задачи. YAML с приходом DevOps стал очень популярен, и для этого есть причины. Для человека, который пишет конфигурации YAML оказался более читабелен и удобен, чем JSON. Так-же при diff в YAML будет видно явное различие, у JSON, только если он написан с pretty форматированием, с соблюдением whitespace. у YAML этой проблемы нету, т.к. структура файла изначально определена стандартом. JSON типизирован и предсказуем, у YAML есть нюансы. Всё зависит от задачи и реализации парсера/врайтера. Приложение, которое считывает конфигурацию из YAML рассчитывает на определённую модель данных, которые может конфигурационный yaml содержать, по этому особых проблем с использованием YAML я не вижу. Нюансы, которые могут возникнуть либо вы о них быстро узнаете, когда увидите, что конфигурация себя ведёт не правильно, но скорее всего с большинством описанных проблем вы даже и не столкнётесь.
Всё зависит от ваших задач. Но вы должны осознавать одну вещь. Если вы распространяете ПО, которое должно обновляться. Но вы в него в жёсткую пропишите IP адрес с обновлениями, может приключиться не хорошая ситуация, когда у вас по какой-либо причине сменится IP. Провайдер его вам принудительно изменит, вы смените провайдеры, то ваше ПО уже за обновлениями не достучится. И клиента просить или заставлять менять какой-то IP, где-то в конфигурации или ещё что-то, так себе задачка. Тут имеет смысл в ПО прописывать имя хоста вашего домена/поддомена и через DNS иметь возможность менять IP, по которому ваше ПО будет обращаться. Для этих целей можно либо на домашнем ПК держать Web сервер, с которого будут идти обновления, или лучше всего оплатить VDS/VPS (это не дорого) и там развернуть систему обновлений вашей программы.