Стандартные права (suid, sgid, sticky bit) в unix/linux

Настройка InfluxDB в Unix/Linux

По умолчанию InfluxDB использует порты 8083, 8086, 8090 и 8099. Можно использовать и другие порты — для этого потребуется внести соответствующие изменения в конфигурационный файл. Рассмотрим особенности конфигурирования InfluxDB более подробно.

Проверим какие слушает, можно:

# netstat -natpl | grep -E "80"
tcp        0      0 127.0.0.1:8088              0.0.0.0:*                   LISTEN      4461/influxd        
tcp        0      0 :::8086                     :::*                        LISTEN      4461/influxd        
# 

Проверяем что сервис запущен:

# ps aux | grep influxdb | grep -Ev "grep"
influxdb 4461 0.2 1.2 285200 12880 ? Sl 23:45 0:00 /usr/bin/influxd -pidfile /var/run/influxdb/influxd.pid -config /etc/influxdb/influxdb.conf
#

В конфигурационном файле, открываем его для начала:

# vim /etc/influxdb/influxdb.conf

В нем имеются настройки, которые делятся на группы:

• — Задается некоторые детали для логирования. Можно выставить уровень самого логироваия и указать имя лога;
• — Задаются некоторые настройки веб-интерфейса. Можно задать порт (на нем будет работать внутренний веб-сервер). Так же, можно указать путь к файлам веб-интерфейса;
• — Настройки HTTP API;
• — Задаются некоторые настройки для ввода данных из внешних источников (можно настроить отправку данных в Grafana; Также в этом разделе можно настроить ввод данных по протоколу UDP).
• —Задаются настройки протокола согласования RAFT;
• — Задаются настройки хранения данных;
• —Задаются настройки для работы в кластерном режиме (более подробно они будут описаны ниже;
• — настройки опережающего введения журнала (Write Ahead Logging, WAL).

Открываем конфиг:

# vim /etc/influxdb/influxdb.conf

Приводим к виду:

  
enabled = true  
bind-address = ":8086"      # change to a specific interface if needed 
auth-enabled = true         # will enforce authentication

Для генерации конфига, используйте:

$ influxd config > /etc/influxdb/influxdb.generated.conf

Подключение и создание БД в influxDB

Чтобы подключится, используем:

# influx

Для создания БД, используем следующую команду:

> CREATE DATABASE its_my_first_DB

Где:

its_my_first_DB — Название БД.

Чтобы подключится, используем:

# influx

Чтобы просмотреть какие БД имеются, используем:

> SHOW DATABASES

Использование базы данных в influxDB

Чтобы подключится, используем:

# influx

Чтобы начать использовать БД:

> USE mydb

Запишем некоторые данные в созданную БД:

> INSERT cpu,host=My_server1,region=us_west value=0.88

Или, вставим еще другие данные:

> INSERT temperature,machine=node_1,type=assembly external=13,internal=66

Не очень сложно.

Просмотр данных в influxDB базе

Чтобы подключится, используем:

# influx

Чтобы просмотреть какие БД имеются, используем:

> SHOW DATABASES

Чтобы начать использовать БД:

> USE mydb

И, выбираем данные:

> SELECT * FROM cpu
name: cpu
time                host    region  value
----                ----    ------  -----
1501535158522710659 My_server1 us_west 0.88
> 

Или:

> SELECT * FROM temperature
name: temperature
time                external internal machine type
----                -------- -------- ------- ----
1501535403235325917 13       66       node_1  assembly
> 

InfluxDB поддерживает сложный язык запросов, позволяющий выполнять много разных типов запросов. Например:

> SELECT * FROM /.*/ LIMIT 1
> SELECT * FROM CPU_loading
> SELECT * FROM MEMORY WHERE value > 33243243424

Создание пользователя в influxDB

Создать пользователя можно одним из следующих примерах:

> CREATE USER My_USER WITH PASSWORD 'Your_PW' WITH ALL PRIVILEGES

Или:

> CREATE USER My_USER WITH PASSWORD 'Your_PW'

Выставить права можно:

> GRANT ALL ON My_DB_1 TO My_USER
> GRANT READ ON My_DB_2 TO My_USER2

Все гениальное — просто!

А я на этом завершаю свою статью «Установка InfluxDB в Unix/Linux».

Запустить команду от другого пользователя в Unix/Linux

Иногда, просто необходимо запустить команду от другого пользователя. И существует несколько способов, как это можно сделать. Я расскажу о них в своей статья «Запустить команду от другого пользователя в Unix/Linux».

Запустить команду от другого пользователя в Unix/Linux — способ 1

И так, можно использовать утилиту SUDO. Рассмотрим пример:

$ sudo -H -u Your_another_user -c 'ping linux-notes.org'

Пояснения:

• -H YOUR_HOME: Задает HOME (Переменное окружение для хома конкретного юзера) и по умолчанию — это root.
• -u YOUR_USER: Задаем пользователя от которого будет выполнена команда.
• -c YOUR_COMMAND: Служит опцией для ввода команды.

Как-то так.

Запустить команду от другого пользователя в Unix/Linux — способ 2

Можно использовать утилиту SU. И сейчас приведу несколько примеров.

Логин в root юзера

Чтобы получить рута, выполните:

$ su -

Или:

$ su - root

Запустить команду как root юзер

Вот пример команды:

# su - root -c "YOUR_COMMAND_HERE"

Или

su - -c "YOUR_COMMAND_HERE arg1"

Идем дальше….

Выполнить команду от другого пользователя с помощью su

И так, вот пример:

# su -c "/opt/solr/bin/solr create -c test_solr_core -n solrconfig.xml" -s /bin/sh solr

Created new core 'test_solr_core'

Рассмотрим другой пример:

$ su another_user -c 'ping linux-notes.org'

Или:

$ su - YOUR_USER -c "YOUR_COMMAND_HERE"

Где:

• — — Будет имитировать логин указанного пользователя.
• -c — Служит для указания команды для выполнения (для указанного юзверя).

Как-то так.

Запустить команду от другого пользователя в Unix/Linux — способ 3

И так, можно использовать утилиту runuser. Команда runuser запускает оболочку с заменяющими идентификаторами пользователей и групп. Эта команда полезна только когда вы залогинены как пользователь root. Синтаксис выглядит следующим образом:

# runuser -l YOUR_USER -c 'YOUR_COMMAND_HERE'

Как пример, я покажу следующую строку:

# runuser -l nginx -c 'service nginx start'

PS: Для использования команды runuser пароль не требуется, и он должен запускаться только пользователем root.

Основные опции:

• -l: Создаст оболочку для входа в систему, используя файл runuser-l PAM вместо стандартного.
• -g: Указывает на основную группу.
• -G: Указывает на дополнительную группу.
• -c: Собственно, служит для указания команды.
• –session-command=COMMAND: Передает одну команду в оболочку с  опцией «-c» и не создает новый сеанс.
• -m: Не сбрасывайте переменные среды (ENV).

Вот и все, тема «Запустить команду от другого пользователя в Unix/Linux» завершена.

Деплой манифестов. Модель Pull

Взглянем на изображение ниже.

На скрине схематично показан процесс выката приложения

Разработчик пушит изменения в Git-репозиторий, в данном случае это GitLab, но может быть Bitbucket или GitHub, это неважно. В этом репозитории также хранится ваше описание Kubernetes, это могут быть Helm-чарты или просто манифесты YAML — решать вам в зависимости от ваших предпочтений

Вы можете хранить файлы описания в отдельном репозитории. Но тогда в случае, например, с GitLab, нужно будет воспользоваться хуками для активации выкладки с изменёнными параметрами после сборки образа.

Продолжим. Изменения в коде триггерят активацию пайплайна сборки

Как вы будете собирать изменения тоже неважно — Jenkins, GitLab CI/CD или любой другой механизм. Главное — понять концепцию

Активация пайплайна заставляет сборщик собрать новый образ приложения и опубликовать его в реестре контейнеров. Используйте теги или переменные окружения для версионирования образов.

Далее наш собранный образ проходит автоматические тесты. Затем мы разворачиваем наш релиз — в примере с помощью Helm — в наш кластер Kubernetes. Не забываем про встроенную возможность сделать rollback. В общем, так выглядит стандартная схема деплоя приложения в кластер. Обязательно продумайте, как у вас будет выполняться миграция, как эффективно убрать даунтайм приложения или то, как и куда будут попадать пользователи во время деплоя.

Оглавление

Дисклеймер: Данная статья не несёт в себе практических описаний того, как реализовать выкладку вашего приложения в Kubernetes. Какую конечную версию решения и какие инструменты будете использовать — решать только вам.

Контейнеризированные приложения продолжают захватывать мир. Та революция, которую начал Docker, будет приобретать всё большие масштабы. После Docker к нам в 2014 году, а если брать версию 1.0 — в 2015, пришёл Kubernetes, и, давайте скажем честно, он классный. Он позволяет решать кучу задач в автоматическом режиме, из-за которых вы, скорее всего, как OPS-инженер могли плохо спать по ночам. Kubernetes принёс нам новый уровень абстракций над контейнеризированными приложениями. И сейчас большинство компаний стремятся перетащить в него свою рабочую нагрузку и управлять через него своими приложениями. А там, где есть приложения, нам надо продумать, как мы будем их выкатывать. Об этом сегодня и поговорим.

Установка Lsyncd в Unix/Linux

Процесс установки очень прост и не требует очень больших усилий. Я приведу несколько примеров по установки данной утилиты на различные Unix/Linux ОС.

Установка Lsyncd в Debian/Ubuntu

# apt-get update -y && apt-get update -y

Выполним установку:

# apt-get install lsyncd -y

После установки, переходим к настройке.

Установка Lsyncd в CentOS/RedHat/Fedora

# yum -y update

Выполним установку:

# yum install lsyncd -y

И, установим дополнительные пакеты:

# yum install lua lua-devel pkgconfig gcc asciidoc -y

После установки, переходим к настройке.

Установка Lsyncd в Mac OS X

Ставим себе на машину homebrew:

И выполняем установку:

$ brew install lsyncd

После установки, переходим к настройке.

GitOps подход. Модель Push

Давайте взглянем на схему реализации push-модели.

Данный подход предполагает использование двух репозиториев. В первом репозитории мы храним код нашего приложения. Там же мы храним Docker-файлы для сборки, но не храним Helm-чарты или описания желаемого состояния кластера в простых манифестах или с применением kustomize. Триггер сборки активирует пайплайн, который собирает и тестирует новый образ приложения, а также пушит его в registry.

Затем вносятся изменения в репозиторий с манифестами, которые описывают желаемое состояние кластера. Далее оператор синхронизации — в данном случае представлен Argo CD, однако вы можете использовать Flux2 — определяет, что текущее состояние не соответствует описанному состоянию в репозитории, и приводит кластер к этому состоянию. Оператор синхронизации является приложением, предварительно задеплоенным в кластер. Хранение манифестов в отдельном репозитории с их синхронизацией упрощает ваш CI-пайплайн, избавляя его от задач выката приложения.

Сегодня мы рассмотрели две основные модели CI/CD-доставки кода в кластер Kubernetes. Надеюсь, после этой статьи стало немного понятнее, как реализовать выкладку вашего приложения. По какой модели лучше работать — решать вам. Всё будет зависеть от тех задач, которые выполняет приложение, и от того, из каких компонентов оно состоит

Важно использовать Kubernetes с умом и не забывать, что мы используем инструменты для достижения цели, а не ставим цели, чтобы для них подходили конкретные инструменты.

Инструменты GitOps

Ниже приведены несколько популярных инструментов GitOps, которые вы должны попробовать, работая над рабочими процессами GitOps. Я не буду перечислять Git и Kubernetes, потому что это очевидно!

1. Flux

Flux был создан в 2016 году компанией Weaveworks.

Это оператор GitOps для вашего кластера Kubernetes. Он периодически извлекает удаленный репозиторий Git и ищет новые изменения в файлах манифеста. В случае изменения в репозитории, он применяет изменения к кластеру.

2. ArgoCD

ArgoCD также является оператором GitOps, но с пользовательским веб-интерфейсом. Он смоделирует ваш конвейер GitOps с помощью визуальных элементов и диаграмм. Вы также можете визуализировать свою среду и конфигурации приложений с помощью этого инструмента.

3. Jenkins X

Jenkins X — это решение CICD для кластеров Kubernetes, но отличается от классического Jenkins.

Он используется в качестве инструмента GitOps для создания кластера, развертывания контейнера, автоматического отката и т.д. Когда изменение помещается в репозиторий git, Jenkin X считывает и обновляет свои конфигурации после запуска сборки.

4. WKSctl

WKSctl — это инструмент GitOps, который использует коммиты Git для управления кластером Kubernetes. В режиме работы GitOps кластер настраивается на основе сведений, содержащихся в файлах cluster.yml и machines.yml, сохраненных в Git.

5. Gitkube

Gitkube идеально подходит для разработки. Он использует Git push для создания и развертывания образов докеров в кластере Kubernetes.

Он очень прост в настройке и требует простой аутентификации на основе открытого ключа.

6. Helm Operator

Helm Operator — это оператор Kubernetes с открытым исходным кодом, предназначенный для декларативного управления выпусками диаграммы управления. В сочетании с flux он становится подходящим решением GitOps для автоматизации релизов.

7. Quay

Quay управляется Red-Hat и используется для управления образами / реестра образов. Он обеспечивает безопасность и надежность для управления изображениями. Это не зависит от GitHub; скорее, он работает с локальным реестром образов.

Подготовка к работе

Вам нужен Kubernetes кластер и инструмент командной строки kubectl должен быть настроен
на связь с вашим кластером. Если у вас ещё нет кластера,
вы можете создать, его используя
Minikube,
или вы можете использовать одну из песочниц Kubernetes:

• Katacoda
• Play with Kubernetes

На кластере должен быть хотя бы 1 доступный для работы CPU, чтобы запускать учебные примеры.

Для некоторых шагов с этой страницы понадобится запущенный
сервер метрик
на вашем кластере. Если сервер метрик уже запущен, следующие шаги можно пропустить.

Если вы используете Minikube, выполните следующую команду,
чтобы запустить сервер метрик:

Проверим, работает ли сервер метрик (или другой провайдер API ресурсов метрик,
), выполните команду:

Если API ресурсов метрик доступно, в выводе будет присутствовать
ссылка на .

Запрос ресурсов CPU больше доступного на ноде

Запросы и лимиты CPU устанавливаются для контейнеров, но также полезно рассматривать и Pod
имеющим эти характеристики. Запросом CPU для Pod’а является сумма запросов CPU всех его контейнеров.
Аналогично и лимит CPU для Pod’а — сумма всех ограничений CPU у его контейнеров.

Планирование Pod’а основано на запросах. Pod попадает в расписание запуска на ноде лишь в случае
достаточного количества доступных ресурсов CPU на ноде, чтобы удовлетворить запрос CPU Pod’а.

В этом упражнении мы создадим Pod с запросом CPU, превышающим мощности любой ноды в вашем кластере.
Ниже представлен конфигурационный файл для Pod’а с одним контейнером. Контейнер запрашивает 100 CPU,
что почти наверняка превышет имеющиеся мощности любой ноды в кластере.

Создадим Pod:

Проверим статус Pod’а:

Вывод показывает Pending статус у Pod’а. То есть Pod не запланирован к запуску
ни на одной ноде и будет оставаться в статусе Pending постоянно:

Посмотрим подробную информацию о Pod’е, включающую в себя события:

В выводе отражено, что контейнер не может быть запланирован из-за нехватки ресурсов
CPU на нодах:

Удалим Pod:

Единицы измерения CPU

Ресурсы CPU измеряются в CPU единицах. Один CPU, в Kubernetes, соответствует:

• 1 AWS vCPU
• 1 GCP Core
• 1 Azure vCore
• 1 гипертрединговое ядро на физическом процессоре Intel с Гипертредингом

Дробные значения возможны. Контейнер, запрашивающий 0.5 CPU, получит вполовину меньше ресурсов,
чем контейнер, запрашивающий 1 CPU. Можно использовать окончание m для обозначения милли. Например,
100m CPU, 100 milliCPU и 0.1 CPU обозначают одно и то же. Точность выше 1m не поддерживается.

CPU всегда запрашивается в абсолютных величинах, не в относительных; 0.1 будет одинаковой частью от CPU
для одноядерного, двухъядерного или 48-ядерного процессора.

Что такое GitOps?

GitOps — это процесс, который используется для непрерывного развертывания облачного приложения. Этот процесс ориентирован на разработчиков, и для управления инфраструктурой используется удобный для разработчиков инструмент, такой как Git. Git — это единственный источник истины для всей автоматизации развертывания инфраструктуры и приложений.

Это операционная среда, в которой используются лучшие практики DevOps, используемые для разработки приложений. Это контроль версий, совместная работа, соответствие требованиям, CI / CD, и он применяет их для автоматизации инфраструктуры. В двух словах, GitOps состоит из трех основных компонентов.

Это комбинация инфраструктуры как кода ( IaC ), запросов на слияние и автоматизации CI/CD.

Настройка и использование Lsyncd в Unix/Linux

Чтобы все хорошо работало, нужно сгенерировать RSA ключ и положить его на удаленный сервер. Я пропущу данный шаг, т.к я это уже сделал, а если не знаете как это сделать вот статья:

Настройка и использование Lsyncd на Mac OS X

И так, я у себя на mac OS X хотел бы настроить lsyncd таким образом, чтобы он синхронизировал все изменения.

И так, я установил данную утилиту и следующим действием, я создам папку где будет хранится лог-файлы:

$ mkdir /usr/local/var/log/lsyncd

И создаю нужные файлы:

$ touch /usr/local/var/log/lsyncd/lsyncd.{log,status}

PS: В ОС Linux они могут лежать в /var/log/lsyncd. Если не имеется такой папки, то создаем.

Далее, я создаю каталог lsyncd в /etc/ для настройки конфига:

$ sudo mkdir /etc/lsyncd

После создания данной папки, я создаю конфигурационный файл:

# vim /etc/lsyncd/linux_notes.conf.lua

Содержание следующее:

settings  {
    logfile = "/usr/local/var/log/lsyncd/lsyncd.log",
    statusFile = "/usr/local/var/log/lsyncd/lsyncd.status",
    statusInterval = 1,
    nodaemon = off
}
sync {
    default.rsyncssh,
    source = "/Users/captain/tmp",
    host = "captain@31.187.70.238",
    targetdir = "/home/captain/",
    excludeFrom="/etc/lsyncd/linux_notes.exclude",
    delay=3,
    rsync = {
        sparse = true,
        update = true,
        links = true,
        times = true,
        protect_args = false,
        archive = true,
        compress = true,
        whole_file = false,
        acls = true,
        verbose = true
    },
    ssh = {
        port = 22,
        _extra = {"/usr/bin/ssh -l captain -p 22 -i ~/.ssh/id_rsa -o StrictHostKeyChecking=no"}
    }     

}

Иногда нужно исключать некоторые каталоги. Вы можете создать файлe и добавить исключения в строке как в этом примере:

# vim /etc/lsyncd/linux_notes.exclude

.git/*
.*

Теперь мы можем запустить службу lsyncd, выполнив следующую команду:

$ sudo lsyncd /etc/lsyncd/linux_notes.conf.lua -delay 0

Настройка и использование Lsyncd на CentOS

Вот еще пример (проверялось на CentOS 7):

# vim  /etc/lsyncd.conf

И прописываем:

settings  {
    logfile = "/var/log/lsyncd/lsyncd.log",
    statusFile = "/var/log/lsyncd/lsyncd.status",
    statusInterval = 1
}
sync {
    default.rsyncssh,
    source = "/var/www/html",
    host = "31.187.70.238",
    targetdir = "/home/backups/",
    rsync = {
        sparse = true,
        update = true,
        temp_dir="/tmp/",
        links = true,
        times = true,
        protect_args = false,
        archive = true,
        compress = true,
        whole_file = false,
        acls = true,
        verbose = true
     },
     ssh = {
        port = 22,
        _extra = {"/usr/bin/ssh -l captain -p 22 -i /home/captain/.ssh/id_rsa -o StrictHostKeyChecking=no"}
    }     

}

ИЛИ, если использовать RSYNC:

settings = {
 logfile = "/var/log/lsyncd/lsyncd.log",
 statusFile = "/var/log/lsyncd/lsyncd.stat",
 statusInterval = 2,
},
sync{
 default.rsync,
 source="/var/www/html",
 target="31.187.70.238:/home/captain/", 
 rsync={rsh ="/usr/bin/ssh -l captain -i /home/captain/.ssh/id_rsa",}
}

Запускаем демон:

# service lsyncd restart

Добавляем в автозагрузку ОС:

# chkconfig lsyncd on

Если используете CentOS 7:

# systemctl restart lsyncd

И

# systemctl enable lsyncd

Подключаемся к серверу и проверяем папки. Так же, можно посмотреть логи.

Репликация в 2 стороны

Чтобы работала репликация и в обратную сторону — на сервере в другом регионе проведите такие же настройки, но в файле конфигурации lsyncd укажите адрес первого сервера. Проверьте, что данные реплицируются и в обратном направлении. В конфигурации lsyncd уже указана временная директория temp_dir, использование которой необходимо для двусторонней синхронизации.

Репликация на несколько серверов

Вот пример конфиругации:

settings = {
   delay        = 1,
   maxProcesses = 3,
   logfile = "/var/log/lsyncd/lsyncd.log",
   statusFile = "/var/log/lsyncd/lsyncd.stat",
}

targetlist = {
 "66.66.66.10:/var/www/html", 
 "66.66.66.20:/var/www/html"
}

for _, server in ipairs(targetlist) do
  sync{ default.rsync,
    source="/var/www/html",
	rsyncOps="-rltvupgo"
    target=server
  }
end

На этом, у меня все, статья  «Установка Lsyncd в Unix/Linux» завершена.

Установка запроса CPU и лимита CPU

Чтобы установить запрос CPU для контейнера, подключите поле
в манифест ресурсов контейнера. Для установки ограничения по CPU подключите .

В этом упражнении мы создадим Pod, имеющий один контейнер. Зададим для контейнера запрос в
0.5 CPU и лимит в 1 CPU. Конфигурационный файл для такого Pod’а:

Раздел конфигурационного файла содержит аргументы для контейнера в момент старта.
Аргумент говорит контейнеру попытаться использовать 2 CPU.

Создадим Pod:

Удостоверимся, что Pod запущен:

Посмотрим детальную информацию о Pod’е:

В выводе видно, что Pod имеет один контейнер с запросом в 500 милли-CPU и с ограничением в 1 CPU.

Запустим , чтобы получить метрики Pod’a:

В этом варианте вывода Pod’ом использовано 974 милли-CPU, что лишь чуть меньше
заданного в конфигурации Pod’a ограничения в 1 CPU.

Напомним, что установкой параметра для контейнера было задано попытаться использовать 2 CPU,
однако в конфигурации присутствует ограничение всего в 1 CPU. Использование контейнером CPU было отрегулировано,
поскольку он попытался занять больше ресурсов, чем ему позволено.

Заметка: Другое возможное объяснение для выделения менее 1.0 CPU в отсутствии на ноде достаточного количества
свободных CPU ресурсов. Напомним, что в начальных условиях для этого упражнения было наличие у кластера
хотя бы 1 CPU, доступного для использования. Если контейнер запущен на ноде, имеющей в своём распоряжении всего 1 CPU,
контейнер не сможет использовать более 1 CPU независимо от заданных для него ограничений.

Удалим Pod:

Установка Nessus на Debian/Ubuntu/Mint

Nessus является проприетарным сканером уязвимостей в Unix\Linux, который разрабатывается в Tenable Network Security. Его можно бесплатно использовать для личного пользования.

По данным опросов, проведенных sectools.org, Nessus является самым популярным в мире сканером уязвимостей, заняв первое место в 2000, 2003 и 2006 на улучшение безопасности. По оценкам Tenable Network Security, известно что он используется более чем 75 000 организаций по всему миру.

Установка Nessus на Debian/Ubuntu/Mint не займет много времени и не очень сложная. В своей теме «Установка Nessus на Debian/Ubuntu/Mint» я это сейчас покажу как можно сделать (на примере ОС — Debian).

1. Проверяем версию и релиз ОС:

# uname -a
# lsb_release -a

У меня это Debian 7 (32 бит), по этому я скачаю для свой операционной системы данную утилиту.

Перейдем в нужную директорию, я всегда использую:

# cd /usr/local/src

Если у Вас Debian 6 или 7 а так же Kali Linux (32 бит):

# wget  "http://downloads.nessus.org/nessus3dl.php?file=Nessus-5.2.7-debian6_i386.deb&licence_accept=yes&t=054bf0d5344189e8b3ad3a09bcb642bd" -O nessus_32.deb

Если у Вас Debian 6 или 7 а так же Kali Linux (64 бит):

# wget "http://downloads.nessus.org/nessus3dl.php?file=Nessus-5.2.7-debian6_amd64.deb&licence_accept=yes&t=054bf0d5344189e8b3ad3a09bcb642bd" -O nessus_64.deb

Если у Вас Ubuntu 12/13 (32 бит):

# wget "http://downloads.nessus.org/nessus3dl.php?file=Nessus-5.2.7-ubuntu1110_i386.deb&licence_accept=yes&t=054bf0d5344189e8b3ad3a09bcb642bd" -O nessus_32.deb

Если у Вас Ubuntu 12/13 (64 бит):

# wget "http://downloads.nessus.org/nessus3dl.php?file=Nessus-5.2.7-ubuntu1110_amd64.deb&licence_accept=yes&t=054bf0d5344189e8b3ad3a09bcb642bd" -O nessus_64.deb

Если не получится скачать и Вы не знаете почему, то попробуйте выполнить это с правами администратора.

3. Установка Nessus. 

Чтобы произвести установку нужно выполнить:

# dpkg -i имя_пакета

В моем случае я выполняю:

# sudo dpkg -i nessus_32.deb

Начнется установка, пройдет некоторое время, пока установится все нужным образом ( не более пару минут).

4. Запуск программы Nessus. 

Когда у нас уже установлена программа, то ее нужно запустить, для этого выполним команду:

# /etc/init.d/nessusd start

5. Создаем пользователя для работы в Nessus

# /opt/nessus/sbin/nessus-adduser

6. Открываем ваш браузер и переходим в меню утилиты Nessus.https://your_ip_domain:8834

Попадаем на следующий слайд и нажимаем на кнопку «Download plagin», я так понимаю он нужен для работы самой программы. Он устанавливается минуты 3-4. После окончания, вводим логин и пароль которые мы создавали в пункте 5и начинаем проверять систему.

А на этом данная установка Nessus на Debian/Ubuntu/Mint завершена, программа установлена и можно ею пользоваться, надеюсь понятно все было как я описал на своем сайте http://linux-notes.org

Модели доставки кода в кластер

И вот тут я должен сделать первое и главное для нас уточняющее разъяснение. На мой взгляд, существует две модели доставки кода в кластер — условные Pull и Push. В модели Pull мы передаём новое желаемое состояние кластера путём применения манифестов через kubectl, Helm, Kustomize или любым другим методом. В модели Push реализован подход GitOps.

В кластере Kubernetes есть механизм, который следит за Git-репозиторием, и в случае изменения в нём кода, этот механизм приводит кластер в состояние, чётко описанное этим кодом. Почему это хорошо? Потому что у вас есть один источник правды — SST (Single Source of Truth). Допустим, ручное изменение количества ReplicaSet c двух до трёх не будет сохранено на долгое время, так как механизм согласования вернёт кластер в состояние, описанное в Git-репозитории.