Ихрь постит в уютный бложик: заметки с тегом devops

Change SSH port on Ubuntu 22 using Ansible

Wed, 29 Mar 2023 18:46:00 +0300

After updating Ubuntu 22.10 SSHd uses socket-based activation.
As a result, the sshd configuration port does not affect the listening port.
To change the port, we need to perform the following tasks:

- name: Create config folder
  file:
    path: /etc/systemd/system/ssh.socket.d
    state: directory
    recurse: true

- name: Create config file
  copy:
    dest: /etc/systemd/system/ssh.socket.d/listen.conf
    content: |
      [Socket]
      ListenStream={{ custom_ssh_port }}

- name: Reload systemd manager
  systemd:
    daemon_reload: yes

- name: restart ssh
  service:
    name: "ssh"
    state: restarted

- name: Update connection port
  set_fact:
    ansible_ssh_port: "{{ custom_ssh_port }}"

Как хостить MySQL на маленьких VPS

Tue, 22 Mar 2022 17:20:29 +0300

Недавно я начал хостить бложик (apache + mysql + nginx + пара сервисов на nodejs) на самом дешевом дроплете от Digital Ocean (надо ж кредитные токены DO куда-то потратить).

Внезапно столкнулся с проблемой, что контейнер MySQL периодически умирает от OOM киллера, MySQL с небольшим количеством данных съедала ну очень много памяти в простое.

Платить больше я не хотел, а воспоминания, что когда-то MySQL крутилась у меня на прямо маленьких VPS никак не давала покоя.

Оказалось, что есть такая штука, как Performance Schema.

The MySQL Performance Schema is a feature for monitoring MySQL Server execution at a low level.
The Performance Schema provides a way to inspect internal execution of the server at runtime.

Дальше я не особо читал, конечно, погуглил чуть, решил поэкспериментировать.
Добавляем в конфиг в секцию [mysqld] строчку, чтобы отключить эту фичу (я просто примонтировал новый конфиг), перезагрузил сервис и бах — случилась магия и теперь MySQL кушает гораздо меньше ресурсов. А мониторить мне пока не к чему.

Обходим блокировку аналитики AD блокерами

Mon, 22 Feb 2021 13:14:12 +0300

AD-блокеры — несомненно крутая штука, тем не менее, они блокируют скрипты аналитики, которые не всегда являются злом.

Например, аналитика от Cloudflare — про приватность и легкость, данных лишних не собирает, на сторону их не продает. Потому обойти ее блокировку различными расширениями не так уже и подло.

Блокировщики работают в несколько этапов: блокируют подгрузку файла скрипта аналитики и блокируют запросы к серверам аналитики, к которым эти скрипты и обращаются.

Для обхода блокировки нам понадобится одна вещь — прокся с возможностью замены части контента в ответе, например, nginx.

Добавляем два локейшена в конфиг:

# сам скрипт аналитики
location /analytics-script.js {
  # очень важно, чтоб отрабатывал sub_filter, т.к. если сервер отдаст gzip, то замена не сработает
  proxy_set_header Accept-Encoding "";

  # заменяем в скрипте оригинальный адрес на наш, проксированный
  sub_filter 'https://cloudflareinsights.com/cdn-cgi/rum'  'https://домен/analytics-api';
  sub_filter_types *;
  sub_filter_once off;

  proxy_hide_header Content-Security-Policy;
  proxy_pass https://static.cloudflareinsights.com/beacon.min.js;
}

# проксируем вызовы к оригинальному api аналитики
location /analytics-api {
  proxy_pass https://cloudflareinsights.com/cdn-cgi/rum;
}

Подключаем аналитику не с домена Cloudflare, а со своего домена.

Таким образом мы загружаем и скрипт аналитики со своего домена, и аналитику он отправляет на наш домен, а внутри уже все проксируется в Cloudflare.

AD блокеры ничего не блокируют, мы получаем аналитику. Запросы куда-то еще уходят неявно.

Есть одна небольшая проблема — у всех запросов один IP, IP прокси, почему-то аналитика Cloudflare не учитвает заголовки и не имеет задокументированных способов переопределить IP юзера, как это сделано в Google аналитике.

Закинул в коммьюнити топик на эту тему, посмотрим, как решится.

Docker’изация JavaScript-приложений

Fri, 30 Nov 2018 18:03:02 +0300

Поучаствовал в IT-Субботнике, рассказал о Docker’изации JavaScript-приложений.

Docker + Nginx + Env

Thu, 06 Sep 2018 18:01:56 +0300

Иногда бывают ситуации, когда внутри nginx-конфига надо сделать что-то в зависимости от переменной окружения, которая прокинется откуда-то извне (или не прокинется), так помимо этого это всё ещё и в Docker крутится, в который окружение прокидывается от compose или k8s.

С выше изложенными условиями выполнить эту задачу по-простому не получится (ну или я не нашёл как). Решение, представленное ниже, не особо-то и сложное, но, на мой взгляд, несколько нетривиально, ну и, если б я нашёл другой способ, то такой огород городить точно не стал бы.

Итак, ближе к делу, берём и переписываем наш Dockerfile следующим образом.

FROM # какой-то образ

WORKDIR /usr/src/app
COPY . /usr/src/app

ENTRYPOINT ["/usr/src/app/start.sh"]

EXPOSE 80

Ключевой момент здесь — ENTRYPOINT, им является какой-то sh-файл (не забудьте ему права на выполнение дать). Этот файл будет преобразовывать наш nginx-конфиг и запускать nginx.

#!/bin/sh

export SEARCH="${SEARCH_FROM_ENV:-google}"

envsubst '${SEARCH}' < /etc/nginx/nginx.conf > /etc/nginx/nginx.conf

nginx -g 'daemon off;'

В строчке экспорта мы “отдаём” переменную SEARCH, которую читаем из переменной окружения “SEARCHFROMENV”.
В случае, если переменная окружения не задана, присваиваем стандартное значение “google”.
После чего обращаемся к системной утилите envsubst, которой конкретно указываем, какие переменные менять, передаём в неё наш конфиг, а результат выполнения пишем в этот же конфиг.
Наконец, запускаем nginx.
В конфиге nginx изначально указываем где-то выражение следующего вида.

if (${SEARCH} = "google") {
  # что-то делаем
}

После обработки envsubst без передачи каких-либо переменных окружения переменная SEARCH заменится на “google”.

if ("google" = "google") {
  # что-то делаем
}

Таким образом мы прокидываем какую-то env-переменную в nginx-конфиг, а так же, в случае неопределённого окружения, имеем значение по-умолчанию.

GitLab CI & Telegram

Fri, 05 Jan 2018 17:22:20 +0300

Последнее время стал замечать, что всё больше людей юзают GitLab, отмечая, что у него клёвый CI/CD. Не знаю, как правильно всё это оценивать, но попробовать я решил однозначно.

Во-первых, переместил статические сайтики с GitHub Pages на GitLab Pages. Во-вторых, сделал небольшое ExpressJS-приложение и разместил на GitLab, а так же настроил деплой на Heroku, что, оказалось, очень просто.

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

Ну, раз нет интеграции из коробки, то сделаем сами, причем на данном этапе нужно всего лишь уведомление о статусе деплоя.

Задача поставлена, сложностей никаких (на самом деле они возникали, но это я доки невнимательно читал). Делаем.

Чтобы взаимодействовать с Telegram создадим бота: пишем @BotFather, создаём обычного бота, загружаем аватарку и т. п. Всё это делается максимально просто. После создания бота в чатик прилетит token для работы с API.

Бот будет слать уведомления пользователю с нужным ID, но просто так Telegram не позволяет рассылать сообщения от бота любому пользователю, поэтому новосозданному боту нужно отправить хотя бы какое-то сообщение от пользователя, которому должны приходить уведомления.

Сохраняем нужные значения в GitLab:

Settings нужного репозитория;
Пункт CI/CD;
Secret variables;
Сохранить в переменную TELEGRAM_BOT_TOKEN token, присланный после создания бота через BotFather;
В TELEGRAM_USER_ID сохраняем ID пользователя, которому будут отправляться уведомления.

Для удобной отправки уведомлений создадим скрипт в `ci-notify.sh`, в котором будем обращаться к API Telegram и отправлять сообщение нужному пользователю через созданного бота:

#!/bin/bash

TIME="10"
URL="https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/sendMessage"
TEXT="Deploy status: $1%0A%0AProject:+$CI_PROJECT_NAME%0AURL:+$CI_PROJECT_URL/pipelines/$CI_PIPELINE_ID/%0ABranch:+$CI_COMMIT_REF_SLUG"

curl -s --max-time $TIME -d "chat_id=$TELEGRAM_USER_ID&disable_web_page_preview=1&text=$TEXT" $URL > /dev/null

В качестве первого параметра для этого скрипта должен передаваться статус деплоя. В .gitlab-ci.yml описываем вызов этого скрипта в нужное время с нужными параметрами:

stages:
- deploy
- notify

deploy:
  image: node:4.2.2
  stage: deploy

  script:
  #deploy success
  - sh .ci-notify.sh ✅

  artifacts:
    paths:
    - public
  only:
  - master

notify_error:
  stage: notify
  script:
  - sh .ci-notify.sh ❌
  when: on_failure #deploy fail

Для обозначения статуса деплоя я использовал Emoji. В случае успешного выполнения деплоя просто вызывается скрипт с нужны параметром. В случае неудачного деплоя “управление переходит” в следующий stage, в котором происходит уведомление о неудачном деплое.

Таким образом, где-то за 10 минут можно настроить простые уведомления в Telegram из GitLab CI и хоть чуть-чуть почувствовать себя DevOps’ом. Если подзаморочиться, то можно расширить возможности всего этого, но мне как-то лень.

Запуск Karma в Chrome — Travis-CI

Mon, 27 Mar 2017 17:05:37 +0300

Если вы тестируете свой код и используете GitHub, то скорее всего вы уже используете Travis, однако, при тестировании JavaScript в Travis может возникнуть проблема — Travis не умеет запускать тесты в Chrome, но преодолеть её можно всего несколькими строчками config-файлов.

Для начала нам нужно настроить сам travis, в моём случае `.travis.yml` выглядит следующим образом:

language: node_js
node_js:
- '6.2'
before_install:
- export CHROME_BIN=chromium-browser
- export DISPLAY=:99.0
- sh -e /etc/init.d/xvfb start
- sudo apt-get update
- sudo apt-get install -y libappindicator1 fonts-liberation
- wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
- sudo dpkg -i google-chrome*.deb
script:
- npm install
- npm test

Внимание здесь стоит обратить на блок `before_install`.

Для Karma тоже нужно несколько изменить файл настроек — создадим лаунчер, который будет использоваться только в окружении Travis:

module.exports = function (config) {
    var configuration = {
        // configs
        
        browsers: ['Chrome'],
        customLaunchers: {
            Chrome_travis_ci: {
                base: 'Chrome',
                flags: ['--no-sandbox']
            }
        },
      
        // configs
    };

    if (process.env.TRAVIS) {
        configuration.browsers = ['Chrome_travis_ci'];
    }

    config.set(configuration);
}

На этом процедура настройки закончена — пушим изменения на Github и можем наблюдать процесс тестирования в “консоли” Travis соответствующего репозитория.