Выражу своё субъективное мнение на тему именования веток / тасок. В случае, когда дело доходит до автоматизации (и такое есть), очень кашерно иметь чёткую и структурированную логику в именовании. И как правило, банального DEV-1234 бывает достаточно. Теперь касаемо того, как это было на моей практике. Коллега вводит в инструментарии описание к спринту, добавляет задачи и создаёт таски в Jira, Confluence (в ней было как описание работ для инженеров, так и описание к тому, что входит в таску/релиз и т.д.), а далее в Git просто создавались ветки.
Приветствую! Данная статья является одним из кейсов, аля "Как можно зайти в дом". Certbot выпускал в основном для LE-сертификатов, не доводилось менять его логику на что-то другое.
Если так получилось, что в компании хочется выпускать сертификаты со своим CA и приклеивать к своим внутренним сервисам - данный кейс поможет решить проблему (в том числе и обновление). Больше решений - больше выбора =)
The keystore is created same as the truststore (see command above as keystore). in my case I left them the same, but in a production environment it is important to separate them. If memory serves, in production env for keystore need provide server cert (full chain) and key. Trustore need provide only root and intermediate cert
Hi rafy. For this example, you may add cert to keystore (for create connection between nifi and registry). First time, you need to find CA and intermediate certificate (may to create, buy or etc.). For second time, place it as cert.crt (its 2 commands, just replace cert.crt and alias). You need to do it at nifi and registry, because servers are auth by Owner in certificate. For my example, i take certs (root and intermediate) from idm servers.
Приветствую! Один из самых простых примеров - это преобразование данных. Представь, что у тебя есть большой поток XML/JSON, логи разных приложений, какие то данные из БД. Далее, с помощью Nifi, ты эти данные можешь преобразовывать (и преобразовывать не целиком, а постепенно, что в свою очередь делает процесс удобным для тебя) - преобразовывать в единый формат, используя процессоры и другие сущности Nifi. На выходе, ты эти данные можешь затолкать куда-нибудь, где сможешь это визуализировать.
В голову также пришли следующие примеры: - Преобразование таблиц в одну большую; - Преобразование форматов (XML -> Json); - Получение данных из веба (пускай это будут комментарии), преобразование и обработка, получение конкретного типа (пускай, это будут плохие отзывы); - Получение данных из IoT устройств, обработка и визуализация под конкретные паттерны; - Работа с логами;
Понятное дело, что подобные задачи можно решать и командной строкой, но с Nifi ты сможешь всё это выполнять, используя один интерфейс, автоматизируя и не храня всё это в крон скриптах на серверах, забыв об этом через месяц работы.
В целом, никто тебе не мешает использовать ELK, Kafka и другие решения, цель статьи - предоставить вводную для изучения и настройки конкретно Nifi.
Если интересно - могу поработать над описанием конкретных сущностей, с примерами и какими-нибудь простыми кейсами.
Забыли про большой бум с Java, который заставлял школьников выгорать от Log4j. Самое интересное, что в тот период на YouTube было полно обучающих роликов, как использовать этот уяз в своих целях. Также бывают случаи, когда можно и без уязвимостей получать доступ к терабайту данных. Вспомнить только нашумевшую историю с EA и куками сотрудника, которые были слиты в даркнете за 10$
Спасибо за статью, было интересно почитать!
Выражу своё субъективное мнение на тему именования веток / тасок. В случае, когда дело доходит до автоматизации (и такое есть), очень кашерно иметь чёткую и структурированную логику в именовании. И как правило, банального DEV-1234 бывает достаточно. Теперь касаемо того, как это было на моей практике. Коллега вводит в инструментарии описание к спринту, добавляет задачи и создаёт таски в Jira, Confluence (в ней было как описание работ для инженеров, так и описание к тому, что входит в таску/релиз и т.д.), а далее в Git просто создавались ветки.
И правда - очепятка с моей стороны. Спасибо что указал
Приветствую! Данная статья является одним из кейсов, аля "Как можно зайти в дом".
Certbot выпускал в основном для LE-сертификатов, не доводилось менять его логику на что-то другое.
Если так получилось, что в компании хочется выпускать сертификаты со своим CA и приклеивать к своим внутренним сервисам - данный кейс поможет решить проблему (в том числе и обновление). Больше решений - больше выбора =)
The keystore is created same as the truststore (see command above as keystore). in my case I left them the same, but in a production environment it is important to separate them. If memory serves, in production env for keystore need provide server cert (full chain) and key. Trustore need provide only root and intermediate cert
Hi rafy. For this example, you may add cert to keystore (for create connection between nifi and registry). First time, you need to find CA and intermediate certificate (may to create, buy or etc.). For second time, place it as cert.crt (its 2 commands, just replace cert.crt and alias). You need to do it at nifi and registry, because servers are auth by Owner in certificate. For my example, i take certs (root and intermediate) from idm servers.
Приветствую! Один из самых простых примеров - это преобразование данных. Представь, что у тебя есть большой поток XML/JSON, логи разных приложений, какие то данные из БД. Далее, с помощью Nifi, ты эти данные можешь преобразовывать (и преобразовывать не целиком, а постепенно, что в свою очередь делает процесс удобным для тебя) - преобразовывать в единый формат, используя процессоры и другие сущности Nifi. На выходе, ты эти данные можешь затолкать куда-нибудь, где сможешь это визуализировать.
В голову также пришли следующие примеры:
- Преобразование таблиц в одну большую;
- Преобразование форматов (XML -> Json);
- Получение данных из веба (пускай это будут комментарии), преобразование и обработка, получение конкретного типа (пускай, это будут плохие отзывы);
- Получение данных из IoT устройств, обработка и визуализация под конкретные паттерны;
- Работа с логами;
Понятное дело, что подобные задачи можно решать и командной строкой, но с Nifi ты сможешь всё это выполнять, используя один интерфейс, автоматизируя и не храня всё это в крон скриптах на серверах, забыв об этом через месяц работы.
В целом, никто тебе не мешает использовать ELK, Kafka и другие решения, цель статьи - предоставить вводную для изучения и настройки конкретно Nifi.
Если интересно - могу поработать над описанием конкретных сущностей, с примерами и какими-нибудь простыми кейсами.
Забыли про большой бум с Java, который заставлял школьников выгорать от Log4j. Самое интересное, что в тот период на YouTube было полно обучающих роликов, как использовать этот уяз в своих целях.
Также бывают случаи, когда можно и без уязвимостей получать доступ к терабайту данных. Вспомнить только нашумевшую историю с EA и куками сотрудника, которые были слиты в даркнете за 10$