Tech notes

How to Hide Modal App Behind Cloudflare Zero Trust

Fri, 03 Apr 2026 00:00:00 +0000

Why you might need this

To remove your app from public access without implementing auth in code
To integrate the app with your company’s existing access model
To use Google (or another provider) auth on the cheap

Downsides

This is not suitable for production or high load, since cloudflared isn’t designed for heavy traffic and will become a bottleneck
Latency will increase, as traffic will follow the additional hops: Cloudflare Edge Servers → Your cloudflared installation → Modal

Prerequisites

You have a Team or Enterprise plan on Modal (required for custom domain support)
It’s assumed you have cloudflared deployed and everything set up in Cloudflare Zero Trust and you’re familiar with Cloudflare Zero Trust concepts

Algorithm

Attach your custom domain to Modal and verify it (https://modal.com/docs/guide/webhook-urls#custom-domains). This is needed so Modal’s infrastructure “sees” your domain and you can use it as an entry point.
Deploy the app with the custom domain and make sure everything works (without auth for now).
Create a Cloudflare Zero Trust Application: specify access policies, auth method, and the app domain (same as your custom domain), then bind it to the tunnel.
In the tunnel settings, add a route from your_custom_domain to Modal’s standard web endpoint (https://<source>--<label>.modal.run).
If your app’s cold start is fairly long, consider bumping the Connect Timeout in the route settings from the default 30 seconds.
In your DNS provider, change the CNAME record from your_custom_domain: cname.modal.domains to your_custom_domain: cf_tunnel_id.cfargotunnel.com.

After this, your app will be accessible via the standard URL https://<source>--<label>.modal.run without auth, and via https://your_custom_domain with configured auth policies. To disable access through the standard URL, you can add a redirect in the app code. Check the host HTTP header, and if it doesn’t match your_custom_domain, then redirect to it. You can also handle modal serve development mode there.

CUSTOM_DOMAIN = os.environ.get("MODAL_CUSTOM_DOMAIN", "modal-demo.your-domain.com")
<...>
    @modal.asgi_app(custom_domains=[CUSTOM_DOMAIN])
    def serve(self):
        web = FastAPI(title="Demo (Modal)")

        # Redirect to custom domain if configured.
        # Skip redirect for ephemeral apps (modal serve) — their hosts end with "-dev.modal.run".
        _redirect_enabled = bool(CUSTOM_DOMAIN)

        if _redirect_enabled or HEADERS_DEBUG:
            _allowed_hosts = {CUSTOM_DOMAIN} if _redirect_enabled else set()

            @web.middleware("http")
            async def _domain_middleware(request: Request, call_next):
                if _redirect_enabled:
                    host = request.headers.get("host", "").split(":")[0]
                    is_ephemeral = host.endswith("-dev.modal.run")
                    if not is_ephemeral and host not in _allowed_hosts:
                        target = request.url.replace(
                            scheme="https", hostname=CUSTOM_DOMAIN, port=None,
                        )
                        return RedirectResponse(str(target), status_code=301)

                return await call_next(request)

How it works

I don’t have exact knowledge of Modal’s internal infrastructure, so this is a hypothesis that may contain inaccuracies.

When we create a Modal app with custom_domains attached, Modal’s infrastructure gets instructed that incoming traffic with the host: your_custom_domain header should be routed to our app. With the default DNS settings your_custom_domain: cname.modal.domains, this follows the route browser → cname.modal.domains → app. If we change the DNS record, the route gets longer: browser → Cloudflare network → our cloudflared installation → app, but the host header stays the same, so Modal’s infrastructure still routes traffic to the correct app.

CI/CD for Deploying Flows in Prefect Cloud 2

Thu, 09 Nov 2023 00:00:00 +0000

Initial Requirements

We’ve got a bunch of Python scripts representing various Flows, all packed in one repository.
The goal is to deploy the same Flow in the form of multiple Deployments (with different parameters and schedules).
Also, we need to deploy the Flows in two different environments (Dev and Prod) for testing and debugging.
We prefer defining everything in code rather than messing around with manual configurations in a web interface

What Prefect Offers

The Prefect documentation (https://docs.prefect.io/2.14.3/) is a bit confusing, but after some trial and error, here’s what I found out:

Prefect gives us two methods to execute Flows - using agents and workers (https://docs.prefect.io/2.14.3/guides/upgrade-guide-agents-to-workers/). The difference, as far as I can tell, lies in setting up the underlying infrastructure. With agents, you configure it in the infrastructure block (https://docs.prefect.io/2.14.3/concepts/infrastructure/), and for workers, it’s done through job templates. We opted for agent-based deployments to avoid tweaking our Flows too much.
There are three main ways to deploy our Deployments:
1. prefect deployment build + prefect deployment apply - this lets you set parameters for each Deployment individually. It’s an a bit more legacy command that supports both agent and worker configurations.
2. prefect deploy - it can read the prefect.yaml config file and deploy everything from there, or you can specify parameters for a single deployment, similar to the previous method. This is a newer approach that only works with workers and doesn’t support things like infrastructure blocks. Plus, it has a limitation - it can deploy either a single flow or all the flows listed in prefect.yaml, and you can’t have multiple configs like that in one project.
3. Call the serve or to_deployment functions directly from your Flow code.

Description of Deployment Infrastructure

To keep things simple, we decided to skip storage blocks and store all Flows directly in the Docker image of the agent. This image is also used for CI:

# change to exact version if needed, e.g. 2.8.6-python3.10
# see https://hub.docker.com/r/prefecthq/prefect/tags?page=1
FROM prefecthq/prefect:2-python3.10

RUN /usr/local/bin/python -m pip install --upgrade pip

WORKDIR /opt/prefect

ENV PYTHONPATH "${PYTHONPATH}:/opt/prefect/"
ENV PREFECT_QUEUE "default"

COPY requirements.txt /opt/prefect/requirements.txt
RUN pip install -r requirements.txt
RUN prefect block register -m prefect_aws.ecs

COPY src /opt/prefect/src/
COPY flows /opt/prefect/flows/

# default CMD for agent
# workers will be spawned with their own cmd
CMD [ "sh", "-c", "prefect agent  start -q ${PREFECT_QUEUE}" ]

For Deployments, we chose the first deployment method - using prefect deployment build. We wanted to continue defining the infrastructure alongside the Flow in code (as infrastructure blocks). The method of “deploy everything from the project” didn’t suit us because we needed to deploy flows in two different environments in different stages of development.

However, the idea of having a config file describing all deployments was quite handy. So, we came up with our own wrapper that reads our YAML config specifying deployments for a specific environment.

Here’s the script we came up with:

import yaml
import sys
import subprocess
import json
from  shlex import quote

def read_yaml_file(file_path):
    try:
        with open(file_path, 'r') as yaml_file:
            data = yaml.safe_load(yaml_file)
            return data
    except FileNotFoundError:
        print(f"Error: File '{file_path}' not found.")
    except Exception as e:
        print(f"Error: {e}")

# construct_prefect_command accepts two parameters:
# deployment - dict with deployment parameters (see examples in prefect-deployments-dev.yaml)
# ib_block - infrastructure block with AWS creds and ECS config (located in the infrastructure folder)
def construct_prefect_command(deployment, ib_block):
    # mandatory fields
    if "entrypoint" not in deployment:
        raise KeyError("'entrypoint' field is mandatory")
    if "name" not in deployment:
        raise KeyError("'name' field is mandatory")

    command = f"prefect deployment build {quote(deployment['entrypoint'])} -n {quote(deployment['name'])} -a --skip-upload -ib {quote(ib_block)}"

    # optional fields
    if "parameters" in deployment:
        command += f" --params={quote(json.dumps(deployment['parameters']))}"

    if "tags" in deployment:
        for tag in deployment["tags"]:
            command += f" --tag={quote(tag)}"

    if "schedule" in deployment:
        if "cron" in deployment["schedule"]:
            command += f" --cron={quote(deployment['schedule']['cron'])}"
        if "interval" in deployment["schedule"]:
            command += f" --interval={quote(deployment['schedule']['interval'])}"
        if "rrule" in deployment["schedule"]:
            command += f" --rrule={quote(deployment['schedule']['rrule'])}"
        if "timezone" in deployment["schedule"]:
            command += f" --timezone={quote(deployment['schedule']['timezone'])}"
        if "anchor-date" in deployment["schedule"]:
            command += f" --anchor-date={quote(deployment['schedule']['anchor-date'])}"

    if "work_pool" in deployment:
        if "name" in deployment["work_pool"]:
            command += f" --pool={quote(deployment['work_pool']['name'])}"
        if "work_queue_name" in deployment["work_pool"]:
            command += f" --work-queue={quote(deployment['work_pool']['work_queue_name'])}"

    return command

if __name__ == "__main__":

    if len(sys.argv) != 2:
        raise OSError("Script accepts exactly one argument: path to deployments YAML config")
    file_path = sys.argv[1]
    yaml_data = read_yaml_file(file_path)
    if yaml_data:
        if "ib-block" not in yaml_data:
            raise KeyError("'ib-block' field is mandatory")
        if "deployments" not in yaml_data:
            raise KeyError("'deployments' field is mandatory")

        for deployment in yaml_data["deployments"]:
            deploy_command = construct_prefect_command(deployment, yaml_data["ib-block"])
            print(f"run {deploy_command}")
            subprocess.run(deploy_command, shell=True, universal_newlines=True, check=True)

The logic is straightforward: parse the YAML file, check its structure, and convert its fields into parameters for the prefect deployment build command. The YAML file has the following structure:

ib-block: "ecs-task/dev" # Mandatory field. Credentials and parameters for ECS from the infrastructure folder

deployments:
  - name: Flow1 # Mandatory field. Deployment name
    entrypoint: "examples/hello_world.py:hello" # Mandatory field. The path to the .py file containing the flow you want to deploy (relative to the root directory of your project) combined with the name of the flow function.
    parameters: # Optional field. Dict with parameters for flow
      number: 42
      name: "Do not panic!"
      env.stage: "dev"
    schedule: # Optional field. Scheduler parameters, "cron", "interval" and "rrule" are supported, see https://docs.prefect.io/2.14.3/concepts/schedules/?h=schedules#schedule-types
      cron: "0 0 * * *"
      timezone: "America/Chicago"
    tags: # Optional field. List of tags for deployment
      - "dev"
      - "some-tag1"
    version: "0.0.1" # Optional field. Deployment version
    work_pool: # Optional fields. Pool and Work Queue names
      name: "pool"
      work_queue_name: "dev"
  - name: Flow2
 <...>

All of this is deployed using Github Actions (some code parts are omitted as they are not relevant to the topic):

name: Deploy to dev
on:
  workflow_dispatch:
  push:
    branches:
      - dev 

jobs:
  build-image:
    name: Build Prefect docker image
    runs-on: ubuntu-latest
    outputs:
      image: ${{ steps.docker_image.outputs.IMAGE }}

    steps:
      - name: Check out code
        uses: actions/checkout@v3

      - name: Build, tag, and push docker image
        id: docker_image
        env:
          REGISTRY: XXXXX
          REPOSITORY: prefect2-worker
          IMAGE_TAG: dev
        run: |
          docker build -t $REGISTRY/$REPOSITORY:$IMAGE_TAG .
          docker push $REGISTRY/$REPOSITORY:$IMAGE_TAG
          echo "IMAGE=${{ env.REGISTRY }}/${{ env.REPOSITORY }}:${{ env.IMAGE_TAG }}" >> $GITHUB_OUTPUT

  blocks:
    name: Prefect Blocks Upload
    runs-on: ubuntu-20.04 # need for glibc compatibility with prefect docker container
    needs: build-image

    container:
      image: "${{ needs.build-image.outputs.image }}" # run in prefect container from the first step

    env:
      PREFECT_API_KEY: ${{ secrets.PREFECT_API_KEY }}
      WORKSPACE_NAME: "example"
      PREFECT_IMAGE: "${{ needs.build-image.outputs.image }}"

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Authenticate to Prefect Cloud and upload block
        run: |
          prefect config set PREFECT_API_KEY=${{ secrets.PREFECT_API_KEY }} 
          prefect config set PREFECT_API_URL=${{ secrets.PREFECT_API_URL }}
          python3 infrastructure/ecs-task-dev.py # upload infrastructure block to prefect cloud

      - name: Blocks creation finished
        run: echo "ECS block built at $(date +'%Y-%m-%dT%H:%M:%S')" >> $GITHUB_STEP_SUMMARY

  deploy-flows:
    runs-on: ubuntu-20.04
    needs: [build-image, blocks]

    container:
      image: "${{ needs.build-image.outputs.image }}" # run in built prefect container from the first step

    steps:
      - uses: actions/checkout@v3

      - name: Authenticate to Prefect Cloud
        run: |
          prefect config set PREFECT_API_KEY=${{ secrets.PREFECT_API_KEY }} 
          prefect config set PREFECT_API_URL=${{ secrets.PREFECT_API_URL }}

      - name: Deploy flows to Cloud
        id: build
        run: |
          python upload_deployments.py prefect-deployments-dev.yaml
          echo "Flows from prefect-deployments-dev.yaml deployed to Prefect Cloud (dev)" >> $GITHUB_STEP_SUMMARY

Conclusion

This solution enabled us to implement the necessary functionality without making any changes to the Flow code. Moreover, since the deployment script is written in Python and is very straightforward, we were able to hand it over to the Data team. This allows them to modify it in the future to better suit their needs.

Как сдампить существующую инфраструктуру в AWS в виде кода

Mon, 30 Jan 2023 00:00:00 +0000

Вводная

💡 Интерфейс AWS придуман инопланетянами для опытов над людьми, поэтому понять, какие сущности у нас там есть - довольно сложно. Гораздо проще сдампить всю информацию в виде инфраструктурного кода и ревьюить её уже там.

Вообще, на рынке довольно много подобных утилит (https://www.reddit.com/r/aws/comments/shb053/is_there_a_good_tool_to_map_out_aws/ - вот тут например перечисляется большое число сервисов), но часть из них подзаброшены, часть идут за деньги, а часть используют managed подход, а давать креды от AWS каким-то дядям не очень хочется.

Так что для дампа информации об инфраструктуре мы будем использовать https://github.com/GoogleCloudPlatform/terraformer - утилиту, сделанную инженерами из Google, что обеспечивает довольно высокий уровень поддержки и доверия к ней. Стандартные средства AWS тоже бы подошли, думаю, но у нас инфра не только в AWS, так что хочется универсальности.

В документации написано, что последняя версия поддерживает Terraform 0.13, но у меня всё отлично завелось и на свежих версиях Terraform (1.2.x и 1.3.x на момент написания статьи).

Алгоритм

Ставим Terraform (рекомендую это делать через https://github.com/tfutils/tfenv, чтобы легко переключаться между версиями)
Ставим Terraformer
Сетапим доступ до AWS (процесс аналогичен сетапу CLI-утилиты aws, Terraform возьмет креды из ~/.aws/credentials)
Создаем необходимую структуру директорий и качаем AWS provider для Terraform

mkdir terraformer
cd terraformer
echo 'provider "aws" {}' > main.tf
terraform init

В результате в директории создадутся все необходимые для работы файлы (.terraform и .terraform.lock.hcl)
Запускаем terraformer обнюхивать нашу инфраструктуру

terraformer import aws --resources=* --regions=us-east-1  -o aws -p  {output}/

Коротко по опциям (если что всё есть в доке - https://github.com/GoogleCloudPlatform/terraformer#readme)
- import aws - импортируй в код инфру из AWS. Помимо Амазона поддерживается несколько десятков других провайдеров, в том числе и CloudFlare
- --resources=* - импортируй все ресурсы. Можно сдампить только определенный тип ресурсов, если нужно будет аудитить только какие-то конкретные штуки например
- --regions=us-east-2 - импортируй данные только с этого региона. По дефолту сдампит со всех регионов. Глобальные сущности (IAM, пользователи например) сдампятся в любом случае
- -o aws - в какую директорию дампить
- -p {output}/ - какую структуру директорий создавать. По умолчанию используется паттерн {output}/{provider}/{service}/ (т.е. код раскладывается по разным директориям в зависимости от сервиса), что в моем случае оказалось не очень удобно
Ну и всё, через какое-то время он вываливает всё описание куда ему сказали и можно начинать ревьюить. В результате выплёвывается как код Terraform (файлы .tf), так и стейт (файлы .tfstate), что удобно.

Известные проблемы

С поддержкой AWS всё хорошо, но у CloudFlare не поддерживаются Cloudflare Pages например
Время от времени вываливает какие-то ошибки, на описании инфраструктуры это не очень сказалось, но скорее всего код для использования в Terraform надо будет допиливать руками

Тулинг для миграции уже созданной инфраструктуры в Terraform

Mon, 30 Jan 2023 00:00:00 +0000

Потратил тут довольно много времени на задачу по перетаскиванию когда-то созданной руками инфры под Terraform. Инфраструктура естественно уже в продакшене, на нее идёт трафик, так что метод “снести всё нафиг и построить новое светлое вечное” не подходил, пришлось менять колёса в автомобиле на ходу. Сильно на алгоритмах переноса останавливаться не буду, всё таки тут всё сильно зависит от конкретной инфры, просто опишу тулинг, который мне в этом помог.

terraform import

Про него рассказывать особо нечего, это часть terraform, которая позволяет “обнюхать” уже имеющийся ресурс и положить его в tfstate. Проблема в том, что этого мало, помимо стейта надо сгенерировать сам код, а руками перекладывать всё из выхлопа terraform plan весьма муторно.

terraformer

Утилита, которая умеет ходить в API AWS, Cloudflare и ряда других сервисов, собирать оттуда информацию об объектах инфраструктуры и генерировать terraform-код и terraform-стейт. По описанию звучит так, будто бы это серебрянная пуля, но на самом деле совсем нет.

Плюсы:

Код действительно генерируется и он даже работает, в большинстве случаев если прогнать по этому коду terraform apply - всё будет ок;
Удобно, когда надо оценить фронт работ и хотя бы просто понять, а насколько много инфраструктуры создано в том же AWS;
Удобно, когда надо сделать “хоть как-то”, например если надо быстро отредачить кучу объектов, то может быть удобно “сдампить” их в terraform-код, отредактировать регуляркой и потом применить измененный код.

Минусы:

Код низкого качества, куча дублированного кода, плохо с взаимосвязями ресурсов. Про модули я вообще молчу;
Не всегда поддерживаются актуальные версии ресурсов, например в aws-провайдере для S3 есть тенденция к дроблению большого ресурса s3_bucket на кучу мелких про policy, про lifecycle и так далее. terraformer дампит всё по старинке в один большой ресурс.

Я обычно использовал его вместе с terraform import для кросс-верификации, чтобы убедиться что сгенерированный код совпадает с импортированным стейтом.

Небольшой гайд по использованию если что есть тут: https://blog.strangeman.info/devops/2023/01/30/terraformer-guide.html

Также есть утилита tfadd, которая умеет генерировать tf-код из стейта (то есть сначала импортируем стейт через terraform import, а потом генерируем из него код через tfadd), но я ей не пользовался.

k2tf и tfk8s

Обе утилиты делают одно и то же - конвертируют YAML-манифесты kubernetes в terraform-код. Стейт предлагается импортировать через terraform import.

tfk8s мне показалась менее удобной, так как генерирует только kubernetes_manifest ресурсы, что выглядит некрасиво. k2tf поумнее, она генерирует ресурсы типа kubernetes_deployment, kubernetes_service и так далее, что позволяет получить более качественный код.

Но у k2tf есть минус - последний коммит был в середине прошлого года, есть ощущение что её подзабросили и в какой-то момент она может перестать поддерживать актуальные версии провайдеров.

tfautomv

Утилита не столько для переноса уже созданной инфры под terraform, сколько для рефакторинга уже имеющегося кода, но сюда она тоже подойдет, так как рефачить всё то что мы надобавляли неизбежно придется.

Суть: вам потребовалось переименовать ресурс, или перенести его куда-то, или ещё что-то. Terraform естественно предложит вам снести старый ресурс и создать с нуля новый. Это может быть очень больно. Для облегчения страданий есть команда terraform state mv и специальные moved-блоки.

Но даже c moved это всё ещё больно. tfautomv эту боль убирает, генерируя эти блоки автоматически. Грубо говоря, он смотрит выхлоп terraform plan и, если видит идентичные ресурсы с разными именами на удаление и добавление, то кладет их в moved-блок. Утилита работает не идеально, особенно если рефакторинг включает в себя не только переименование, но всё равно сильно облегчает жизнь.

Как я новую работу искал

Tue, 26 Jul 2022 00:00:00 +0000

Перекладываю тредик из твиттера сюда, чтобы не потерялось в случае каких-то проблем.

Первоисточник тут: https://mobile.twitter.com/_strangeman/status/1551817451020615681

Небольшой тредик про то, как я собеседовался на новую работу, солью информацию о том, сколько денег нынче девопсам предлагают и что вообще на рынке есть. Может кому-то пригодится, да и просто свой опыт зафиксирую.

Исходные данные, чего искал: позиция Senior/Lead DevOps/Platform/Infrastructure Engineer, обязательно с релокацией в Европу, обязательно в продуктовую компанию. На поиски заложил три месяца, уложился в итоге в четыре недели.

Общался с восемью компаниями, получил пять офферов, одна компания отвалилась на пре-оффере (по локациям не сошлись) и две не ответили на резюме, видимо даже скрининг не прошел. Так что дальше будет инфа по тем шести компаниям, где были непосредственно интервью.

Источники вакансий: две от рекрутеров, которым написал сам (перебрал чаты за год, выбрал адекватных и разослал им CV ), две через рефереров из Вастрик.Клуба (о вакансиях узнал из https://engineer-petr.github.io/), две нашли меня сами через Linkedin и тред “Ищу работу” в Вастрик.Клубе.

Четыре компании русскоязычные/гибридные (часть команд говорят на русском, часть на английском). Полностью англоязычных было только две компании, и то, с моим B2 без разговорной практики я прошел все этапы. Так что без языка уехать вполне реально, подтягивать можно будет в процессе.

Самое популярное место для релокации - Кипр (4 из 6), потом Грузия, Болгария, Сербия, Нидерланды. На первых этапах три компании предлагали Польшу, но потом дали заднюю, говорят что поляки перестали выдавать визы русским.

Почти все компании предлагают два варианта - устроиться в штат в локации где у них есть офис, либо работать контрактором откуда угодно. Все компании явно оговаривали что из РФ работать не получится.

Релокационные пакеты разные, от “билеты + две недели аренды” до “билеты + месяц аренды + 10к евро подъемных” или “билеты + месяц аренды + субсидия на аренду на первый год”. Пакеты включают семью, помогают с документами, визами, вот этим всем.

Денег тоже хотят платить сильно по-разному, от 4.2к net до 6.7k net евро. Две компании дополнительно давали опционы (~100-200к в зависимости от оценки). Какой-то сильной взаимосвязи предложенной суммы и размера компании или суммы и должности не увидел.

По процессу собесов: типовой флоу - скрининг, созвон с HR, техсобес, культурно-процессный собес с CTO/VP of Engineering, преоффер, оффер. В одной компании культурный собес был до техсобеса. В другой - техсобес вел Head of Infra, так что сразу про всё поговорили.

Самый быстрый пайплайн от первого созвона с HR до оффера - четыре дня (три созвона). Самый длинный - 25 дней (четыре созвона). Сроки офферов - 1-2 недели обычно, в паре случаев срок не оговаривали.

Предлагаемые тайтлы: DevOps Engineer (Principal, Senior), Infrastructure Engineer, Head of DevOps, Head of Developer Experience (красиво звучит, блин).

Сами интервью сильно разные, кто-то по харду по технологиям спрашивает, кто-то наоборот в основном про процессы и подходы. Последнее мне конечно более близко и такие ребята были в приоритете. Много спрашивают про облака, много про кубер.

Основные причины отказов от офферов: мало денег (ставил себе планку в 5k net), проблемы с процессами и коммуникацией в компании, ощущение, что придется крутить одну и ту же гайку 8 часов в день. В итоге выбрал небольшую компанию с похожим взглядом на процессы со стороны менеджмента.

Источник

https://mobile.twitter.com/_strangeman/status/1551817451020615681

Как превратить кастомный запрос ClickHouse в метрики для Prometheus

Thu, 17 Feb 2022 00:00:00 +0000

Потребовалось тут положить в Prometheus информацию о наличии таблиц на репликах, плюс о движке этих таблиц, чтобы иметь возможность отлавливать ситуации, когда создается таблица без репликации, либо она создается не на всех репликах.

Стандартными метриками эта информация не собирается. Но для решения этой проблемы в ClickHouse есть механизм predefined_query_handler, который позволяет отдавать по заданному URL результаты запроса в необходимом формате.

Как это выглядит в конфигах. В первую очередь, нам надо определиться с запросом. Для нашего кейса он будет выглядеть просто: SELECT database,name,engine FROM system.tables

Теперь этот запрос надо обернуть в корректное форматирование. Для этого используются параметры запроса FORMAT Template и SETTINGS format_template_* (format_template_row, format_template_resultset, format_template_rows_between_delimiter). Эти параметры описаны в документации.

Нам надо задать format_template_row для форматирования каждой строки результата запроса под требования Prometheus. Для этого создаем файл /var/lib/clickhouse/format_schemas/prometheus_table_engine.format:

# TYPE clickhouse_db_engines gauge
# HELP show table engines
clickhouse_db_engines{db_name="${database:Raw}", table="${name:Raw}",engine="${engine:Raw}"} 1

Также нам надо переопределить дефолтное значение format_template_rows_between_delimiter на пустую строку (по дефолту стоит \n и это будет приводить к пустым строкам в списке метрик, что для Prometheus не подойдет).

Теперь нам надо прикрутить этот запрос к какому-нибудь URL в ClickHouse. Это делается через конфиг, через секцию <http_handlers>:

    <http_handlers>
        <rule>
            <url>/table_engines</url>
            <methods>GET</methods>
            <handler>
                <type>predefined_query_handler</type>
                <query>SELECT database,name,engine FROM system.tables FORMAT Template SETTINGS format_template_row = 'prometheus_table_engine.format', format_template_rows_between_delimiter = '' </query>
            </handler>
        </rule>
        <defaults/>
    </http_handlers>

Важно: внутри секции обязательно должно быть поле <defaults/>, иначе отломаются все стандартные эндпойнты.

Итого, при запросе на /table_engines нам вывалится набор метрик по таблицам и их движкам:

curl http://localhost:8123/table_engines

# TYPE clickhouse_db_engines gauge
# HELP show table engines
clickhouse_db_engines{db_name="system", table="replication_queue",engine="SystemReplicationQueue"} 1
# TYPE clickhouse_db_engines gauge
# HELP show table engines
clickhouse_db_engines{db_name="system", table="role_grants",engine="SystemRoleGrants"} 1
# TYPE clickhouse_db_engines gauge
# HELP show table engines
clickhouse_db_engines{db_name="system", table="roles",engine="SystemRoles"} 1
...

Источник

Edit all sentry projects with curl, jq and duct tape

Mon, 23 Dec 2019 00:00:00 +0000

Script

#!/bin/bash

# get token from Sentry
TOKEN="XXXXXXXXXXXXXXXXXXXXXXXXXX"

SENTRY_ROOT=sentry.example.com
SENTRY_ORG=myorg

# easiest way to get payload - look into browser development tools and copy endpoints and jsons
DATA='{"allowedDomains":["*.example.work", "*.example.net", "*.example.io"]}'

# get all projects
APPS=$(curl -sb -H "Accept: application/json"  -H "Authorization: Bearer ${TOKEN}" https://${SENTRY_ROOT}/api/0/organizations/${SENTRY_ORG}/projects/ | jq -r '.[].slug')

# put settings to all projects
for APP in ${APPS}; do
  curl "https://${SENTRY_ROOT}/api/0/projects/${SENTRY_ORG}/${APP}/" -X PUT -H 'Content-Type: application/json' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' -H "Authorization: Bearer ${TOKEN}" --data ${DATA}
done

Итоги 2018 года

Mon, 07 Jan 2019 00:00:00 +0000

Минусы

Низкая физическая активность. Шевелился сильно меньше, чем в прошлые годы. Меньше велосипеда, меньше игр, меньше прогулок. Как результат - довольно заметно расплылся и начало барахлить то тут, то там в теле;
Здоровье. Частично связано с прошлым пунктом, частично с чем-то еще, надо разбираться. Количество болячек заметно увеличилось, к сожалению.

Плюсы

Психотерапия. В июне закончил регулярные встречи с терапевтом, но стреляет до сих пор, постоянно вылезают те истории, которые “в теории” проговаривали на консультациях, и это очень круто. Это самое ценное, что произошло за год. Стало сильно больше порядка внутри - становится сильно проще наводить порядок снаружи меня. Из побочек - это наведение порядка снаружи, конечно, влияет на окружающих. Разошелся с девушкой. Разругался с сестрой, разругался с мамой, постепенно учимся общаться по-новому. Стало сильно больше свободы внутри, меньше стыда, зажимов и сожалений, как следствие - меньше внутреннего давления и потребности его снимать алкоголем, ебанутым поведением и прочим деструктивом. Стало меньше “я паршивый отец” в голове;
Люди. Сильно вырос (и в какой-то мере сменился) круг общения. Важные для меня старые связи, по счастью, почти не рвались (в основном терялись слабые связи), зато появилась масса новых, как слабых, так и сильных;
Путешествия. В лайт-режиме покатался по России, пару раз в Москву (там холодно и шумно, но красиво), посмотрел на Крым (там тепло и красиво);
Работа. Hard-skills, на мой взгляд, выросли слабо, качественных скачков как в 2016-2017 не было. Зато выросли soft-skills, повыступал с докладами как внутри компании, так и “снаружи”, на Uptime Day;
Финансы. Кажется, это первый год в моей жизни, когда я спокойно мог планировать бюджеты. Кончилась суета и запара. А может просто перестал заливать бесполезными покупками дырки внутри (см. выше про ебанутое поведение и бухлишко).

Планы

Получить права, ибо к 30 годам возникла потребность;
Снова начать бегать и в целом больше заботиться о себе, ибо сидячая работа сама себе кровь не разгонит и здоровью не поспособствует;
Хочу в Грузию! И в Армению! И еще куда-нибудь! И шенген бы сделать. В общем ну вы поняли. План максимум - отправиться в долгоиграющее кочевье по нескольким местам, благо есть несколько успешных примеров перед глазами.

Yet another 'How to speed up Ansible' tips

Wed, 02 Jan 2019 00:00:00 +0000

SSH settings

ansible.cfg

[ssh_connection]
ssh_args = -o PreferredAuthentications=publickey -o ControlMaster=auto -o ControlPersist=60s
pipelining = True

PreferredAuthentications helps to initiate the connection faster (without trying rare gssapi-with-mic,gssapi-keyex,hostbased methods).

ControlMaster and ControlPersist allows multiplexing existing connections to the server.

Useful links: https://serverfault.com/questions/929222/ansible-where-do-preferredauthentications-ssh-settings-come-from

Facts caching

ansible.cfg

[defaults]
gathering = smart
fact_caching=yaml
fact_caching_timeout=86400
fact_caching_connection=./ansible-cache

These options enable fact caching for 1 day and tell Ansible not gather facts in they already presented in the cache.

Useful links:

Profiling

The most important part, in my opinion. There is no universal way, but I have some recomemndations:

Try to make tasks idempotent as possible. No need to do a useless job;
Delete duplicating tasks. For example, you’re may try to enable the firewall every time when you’re installing something. These tasks may be idempotent, but they still consume execution time;
Use something like Ara to visualize the playbook execution. Ara provides a good web interface and allows to sort tasks for execution time.

Useful links: https://github.com/openstack/ara

Анонимизация данных в PostgreSQL базе с помощью Python

Fri, 19 Oct 2018 00:00:00 +0000

Table Of Contents
Постановка задачи
Популярные библиотеки
Реализация

Постановка задачи

Есть дампы баз микросервисов с прода. Перед заливкой их на тест (чтобы гонять тестовую среду на приближенных к боевым объемах данных) хочется заменить там логины, имена, фамилии и адреса почты. Рандомно генерировать не подойдет, тестировщикам будет неудобно работать с Аваолртпщр Пватващитвап. Соответственно, надо взять какое-то решение для генерации фейковых данных.

Помимо этого, после замены базы должны остаться консистентными, во всех базах один и тот же id должен соответствовать одному и тому же пользователю. Также должен быть whitelist пользователей, которых не надо обновлять. Ну и плюс при добавлении баз это все должно довольно легко расширяться.

Писать буду на Python, ибо быстро и куча библиотек на все случаи жизни.

Реализация

Обе библиотеки обладают относительно ограниченным набором данных. В таблицах стояло ограничение на уникальность логина и емейла и в итоге через некоторое время записи начинали повторяться и все падало к хренам. Пришлось добавлять рандомный постфикс к логинам и емейлам. В итоге получился примерно такой класс для генерации фейкового аккаунта:

class MimesisPerson:
  def __init__(self):
    self.first_name = Person('ru').name()
    self.last_name = Person('ru').last_name()
    self.username = Person('ru').username() + "_" + ''.join(random.choice(ascii_lowercase + digits) for _ in range(4))
    self.email = self.username + "_" + Person('ru').email()

Целиком скрипт выглядит примерно так:

import psycopg2
import psycopg2.extras
from mimesis import Person

import random
from string import Template, ascii_lowercase, digits

import config

class MimesisPerson:
  def __init__(self):
    self.first_name = Person('ru').name()
    self.last_name = Person('ru').last_name()
    self.username = Person('ru').username() + "_" + ''.join(random.choice(ascii_lowercase + digits) for _ in range(4))
    self.email = self.username + "_" + Person('ru').email()

class Connection:
  def __init__(self, conn_string, sql):
    self.conn_string = conn_string
    self.sql = sql
    self.connector = psycopg2.connect(self.conn_string)
    self.cursor = self.connector.cursor()

  def update_data(self, person, user_id):
    for query in self.sql:
      self.cursor.execute(query.substitute(user_login=person.username, email=person.email,
                                                     first_name=person.first_name, last_name=person.last_name, user_id=user_id))

# update user info in base1 and base2
base1 = Connection(conn_string=config.base1_conn_string, sql=[
       Template("UPDATE users SET login = '$user_login', email = '$email', first_name = '$first_name', last_name = '$last_name' WHERE id = '$user_id'")
     ])
base2 = Connection(conn_string=config.base2_conn_string, sql=[
       Template("UPDATE users SET username = '$user_login', mail = '$email', first_name = '$first_name', last_name = '$last_name' WHERE id = '$user_id'")
     ])

base_list = [base1, base2]

id_cur = base1.connector.cursor(cursor_factory=psycopg2.extras.DictCursor)
id_cur.execute('SELECT id FROM users')

bulk = 0
entry = 0

for row in id_cur:
  person = MimesisPerson()

  if row["id"] in config.id_whitelist:
    print("Skipping user_id %s"%(row["id"]))
    continue

  try:
    for con in base_list:
      con.update_data(person, row["id"])
  except Exception as e:
    print("Error on %i entry in batch, exiting..."%(bulk))
    print(e)
    break

  bulk+=1
  entry+=1

  if bulk > 100:
    for con in base_list:
      con.connector.commit()
    bulk=0

  if entry % 1000 == 0:
    print("Processed %i entries..."%(entry))

for con in base_list:
  con.connector.commit()
  con.connector.close()

Новые базы при надобности просто добавляются в массив и по ним тоже начинает бегать скрипт.

Benchmarking Python vs Go+Python vs Rust+Python for Vincenty formula

Mon, 15 Jan 2018 00:00:00 +0000

Table Of Contents
Benchmarking Python vs Go+Python vs Rust+Python

Benchmarking Python vs Go+Python vs Rust+Python

Disclaimer

This is not too representative experiment, I just searching the fastest way to compute Vincenty distance for my Telegram Python bot.

Algorithms for Go and Rust are equal (I just rewrote Go code into Rust), ‘plain’ Python uses geopy library.

Rust code may be not ‘rust-way’, but this is my first experience with this language.

All code located here: https://github.com/strangeman/vincenty-benchmark

Environment and tools

OS

$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux buster/sid"

Languages

$ python -VV
Python 3.6.4 (default, Jan  5 2018, 02:13:53)
[GCC 7.2.0]

$ go version
go version go1.9.2 linux/amd64

$ rustc -Vv
rustc 1.23.0 (766bd11c8 2018-01-01)
binary: rustc
commit-hash: 766bd11c8a3c019ca53febdcd77b2215379dd67d
commit-date: 2018-01-01
host: x86_64-unknown-linux-gnu
release: 1.23.0
LLVM version: 4.0

Rust code was compiled with and without -O (allow optimizations) option.

Unfortunately, that code wasn’t compiling with gccgo compiler, so I didn’t test it.

Benchmarking

I used pytest-benchmark 3.1.1. Rust and Go code was compiled to .so library and called from Python code. All sources located in /src directory.

Benchmark parameters: rounds=1000, warmup_rounds=5, iterations=100.

How to run it

You need to have installed Python 3, Go and Rust;
Run make install to install needed Python and Go dependencies;
Run make compile to compile Go and Rust code;
Run make benchmark to run benchmarks.

Results

------------------------------------------------------------------------------------------------- benchmark: 4 tests ------------------------------------------------------------------------------------------------
Name (time in us)                               Min                 Max                Mean             StdDev              Median                IQR            Outliers  OPS (Kops/s)            Rounds  Iterations
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
test_benchmark_distance_rust_optimized      16.6895 (1.0)       35.6014 (1.0)       19.6811 (1.0)       2.8708 (1.0)       19.1832 (1.0)       1.3009 (1.06)      113;103       50.8103 (1.0)        1000         100
test_benchmark_distance_rust_default        22.5512 (1.35)      46.2139 (1.30)      26.5663 (1.35)      3.6022 (1.25)      25.8693 (1.35)      1.2280 (1.0)       113;198       37.6417 (0.74)       1000         100
test_benchmark_distance_go                  34.1294 (2.04)      68.4217 (1.92)      39.2860 (2.00)      3.5562 (1.24)      39.0943 (2.04)      2.7511 (2.24)       181;42       25.4543 (0.50)       1000         100
test_benchmark_distance_python             163.4739 (9.79)     365.9721 (10.28)    186.3141 (9.47)     21.2402 (7.40)     185.2215 (9.66)     15.8129 (12.88)       59;43        5.3673 (0.11)       1000         100
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Several runs show similar results. Full report you can see here.

Looks like Rust code 2x faster than Go and almost 10x faster than Python.

Size of binaries

$ ls -l1h build/

1,4K godistance.h
2,0M godistance.so
2,8M rustdistance_default.so
2,8M rustdistance_optimized.so

Some additional thoughts

Rust looks interesting, but it a bit complex than Go (especially in OOP part). Also, Rust is younger and have less third-party modules and tools.

Kafka operation tips

Tue, 15 Aug 2017 00:00:00 +0000

Table Of Contents
How to increase topic Replication Factor in Kafka
- How to look current topic configuration
- How to change topic Replication Factor
How to increase partition count
How to fix ‘Leader: -1’ for Kafka partition
- How it looks like
- How to fix it

How to increase topic Replication Factor in Kafka

How to look current topic configuration

kafka-topics --topic f6b77500-a1f9-4c1f-8fe1-291ae28aff47  --describe --zookeeper localhost:2181
 
Topic:f6b77500-a1f9-4c1f-8fe1-291ae28aff47  PartitionCount:1    ReplicationFactor:1 Configs:retention.ms=2592000000,segment.ms=86400000
    Topic: f6b77500-a1f9-4c1f-8fe1-291ae28aff47 Partition: 0    Leader: 3   Replicas: 3 Isr: 3

We interested in following parameters:

ReplicationFactor (count of replicas for each partition in this topic)
Isr (ids of replicas which have latest actual data, same as broker.id in kafka config)
Leader (‘main’ node for this partition)

Example 1: ReplicationFactor=3, all nodes are available

kafka-topics --topic 9146aeea-1b19-48a0-9001-c77e35d74721  --describe --zookeeper localhost:2181
 
Topic:9146aeea-1b19-48a0-9001-c77e35d74721  PartitionCount:1    ReplicationFactor:3 Configs:retention.ms=2592000000,segment.ms=86400000
    Topic: 9146aeea-1b19-48a0-9001-c77e35d74721 Partition: 0    Leader: 1   Replicas: 1,2,3 Isr: 1,3,2

Example 2: ReplicationFactor=3, one node is unavailable

kafka-topics --topic 9146aeea-1b19-48a0-9001-c77e35d74721  --describe --zookeeper localhost:2181
 
Topic:9146aeea-1b19-48a0-9001-c77e35d74721  PartitionCount:1    ReplicationFactor:3 Configs:retention.ms=2592000000,segment.ms=86400000
    Topic: 9146aeea-1b19-48a0-9001-c77e35d74721 Partition: 0    Leader: 1   Replicas: 1,2,3 Isr: 1,3

How to change topic Replication Factor

1) Need to create JSON file with new topic configuration, for example:

{"partitions":                       
    [{"topic": "f6b77500-a1f9-4c1f-8fe1-291ae28aff47",                   
      "partition": 0,                   
      "replicas": [1,2,3] }],           
"version":1                          
}

and store it somewhere on Kafka server (/tmp/reassign.json in my case)

2) Then need to apply this file

kafka-reassign-partitions --zookeeper localhost:2181 --execute --reassignment-json-file /tmp/reassign.json
 
Current partition replica assignment
 
{"version":1,"partitions":[{"topic":"f6b77500-a1f9-4c1f-8fe1-291ae28aff47","partition":0,"replicas":[3]}]}
 
Save this to use as the --reassignment-json-file option during rollback
Successfully started reassignment of partitions {"version":1,"partitions":[{"topic":"f6b77500-a1f9-4c1f-8fe1-291ae28aff47","partition":0,"replicas":[1,2,3]}]}

3) Check how reassignment is going

kafka-reassign-partitions --zookeeper localhost:2181 --verify --reassignment-json-file /tmp/reassign.json
 
Status of partition reassignment:
Reassignment of partition [f6b77500-a1f9-4c1f-8fe1-291ae28aff47,0] completed successfully

How to increase partition count

kafka-topics --zookeeper localhost:2181 --alter --partitions 5 --topic 9bd6a5bf-5fdb-4900-91af-c7b6d560968f

How to fix ‘Leader: -1’ for Kafka partition

How it looks like

kafka-topics --topic _schemas --describe --zookeeper localhost:2181
Topic:_schemas    PartitionCount:1    ReplicationFactor:3    Configs:cleanup.policy=compact
    Topic: _schemas    Partition: 0    Leader: -1    Replicas: 1,2,3    Isr:

That partition has no In-Sync Replicas (Isr) and cannot elect a Leader. Usually, that means we can’t read/write from/to this partition.

How to fix it

TIP. We can get a list of all topics that have partitions without Leader with this one-liner:

kafka-topics --describe --zookeeper localhost:2181 | grep "Leader: -1" | cut -f 2 | uniq | cut -f 2 -d " "

Kafka can do Unclean Leader Election. By default, Kafka elects partition leader from in-sync replicas, to guarantee data consistency. But, when the partition has no in-sync replicas, we can switch to a special mode, which can elect a leader from the random available replica. This is the dangerous operation, because we may lose some data, but this is better than nothing.

1) Enable unclean.leader.election.enable=false for topic:

kafka-topics --config unclean.leader.election.enable=true --zookeeper localhost:2181 --topic _schemas --alter
Updated config for topic "_schemas".

2) Restart Kafka

systemctl restart kafka

3) Check that leader was elected and in-sync replicas was appeared

kafka-topics --topic _schemas --describe --zookeeper localhost:2181
Topic:_schemas    PartitionCount:1    ReplicationFactor:3    Configs:unclean.leader.election.enable=false,cleanup.policy=compact
    Topic: _schemas    Partition: 0    Leader: 1    Replicas: 1,2,3    Isr: 3,1,2

4) Disable unclean.leader.election back

kafka-topics --config unclean.leader.election.enable=false --zookeeper localhost:2181 --topic _schemas --alter
Updated config for topic "_schemas".

5) And restart Kafka again

systemctl restart kafka

Ansible-Semaphore UI Walkthrough

Sat, 05 Aug 2017 00:00:00 +0000

Table Of Contents
Introduction
UI Walkthrough

Introduction

Ansible-Semaphore is Open Source alternative for Ansible Tower (Web UI and API for launching Ansible Tasks). Source code hosted on Github under MIT license. Semaphore supports LDAP authentification, bearer tokens for REST API, Telegram and Email alerts for the failed tasks and simple user roles system (under development, see #413 and #405 PRs). It’s written on Go (backend) and Angular (frontend).

UI Walkthrough

Current screenshots taken from Semaphore 2.4.1 + #413 and #405 PRs.

Main Page

List of all appeared events: Task Template/User/Project/Repository/etc Creation/Updating/Deletion, Task status updates, and much more;
Project List and Project Add button.

Global User List

This is the list of all users in Semaphore.

Explanation of some properties:

Alert: user will receive alerts about failed tasks to his email;
Admin: user can create new users and edit their information;
External: user authenticates through external backend (currently only LDAP is supported). Admin can’t edit his username and password.

Global User Edit Dialog

Normal and External user edit dialog:

Main Project Page

Project Settings button and Project Menu:
- Dashboard: this page
- Task Templates: all task templates, available for launch
- Inventory: Semaphore currently supports Static Inventory (same as ordinary Ansible inventory file). Dynamic Inventories not yet supported (see #47). Also, there is possible to use inventory from your playbooks repo (and pass it via Ansible -i flag);
- Environment: variables, related to this project;
- Key Store: SSH keys for playbook repository fetching and ansible SSH connections. Various Task Templates may use various keys;
- Playbook Repositories: list of git repos with playbooks for this project. Currently supported only SSH fetching. Local repos and HTTPS repos isn’t supported;
- Team: list of users belong to this project. Currently, users have 2 properties: Admin user can add new users to the project, Launch-Only user cannot edit or create new items (Task Templates, Inventories, Environments etc) in the project. Admin User can be also a Launch-Only user (e.g. in the case to prevent accidental editing/deletion of items) and can edit this property for himself.
Project activity: list of all events related to this project (similar to Events on the main Semaphore page)
Task history: list of all launched tasks. It contains:
- Task name;
- Playbook name (green - task successful, red - task failed, blue - task running, gray - task waiting in the queue);
- Task start time (in local user time);
- Task duration (rounded to minutes);
- Task initiator.

Project Settings Page

Settings are pretty simple: project name, Telegram chat id for alerting and on/off switch for alerts.

Task Templates Page

Launch-Only User (bottom half of screen) cannot copy or create new task templates.

Task Template Edit Page

You should firstly create Key Store, Playbook Repository, and Inventory items and then create a Task Template item. If you use inventory from your playbook repo, then you should create an empty inventory without any content (will be fixed in #328).

Inventory Page

Red item is marked as removed (it should be deleted, but used by some task templates).

Key List and Key Edit Pages

AWS, Digital Ocean, and Google Cloud can be created, by cannot use because Dynamic Inventory support not yet realized.

Repository List Page

Project Team Page and Add Project User Dialog

Task Launch Process

After clicking on Run button, Semaphore shows Run/Dry Run Dialog:

Then, Semaphore put the task in the queue. Currently, Semaphore can execute only one task from all project at the same time, will be fixed in #366.

If the task on top of the queue, it starts. Semaphore and Ansible logs will be shown to the user and stored in the database.

The user can view any finished task log.

Впечатления от системы мониторинга Sysdig

Mon, 10 Apr 2017 00:00:00 +0000

Общая информация

Ребята из Sysdig делают два продукта: опенсорсную утилиту с htop-like UI для получения подробной информации о том, что вообще происходит в системе и очень продвинутую облачную систему мониторинга, которая из коробки умеет собирать кучу метрик, детектить установленные приложения, работать с контейнерами (как с одиночными контейнерами, так и с compose/swarm/k8s/mesos оркестрацией). Обе этих системы, насколько я понимаю, работают на одном ядре, которое собирает информацию о системе на низком уровне (в процессе установки подсовывается, в том числе, свой модуль ядра) и либо выплевыает это все в ncurses-UI, либо шлет на сервер.

Опенсорсная утилита

По сути, это швейцарский нож, включающий в себя strace, htop, lsof, tcpdump, iftop, docker client и, наверное, что-нибудь еще. Можно смотреть статистику потребления ресурсов (cpu, ram, сеть, диск) по процессам/контейнерам, что и куда шлет по сети каждый процесс/контейнер, ошибки и логи на уровне системы/приложения, трейсы, открытые файловые дескрипторы и так далее и тому подобное. Очень полезной фишкой является возможность записи всего происходящего в системе в специальный файл для последующего анализа. Вот тут есть видео с примерным обзором возможностей, рекомендую посмотреть.

Из минусов - эта вундервафля (при запущенном curses-клиенте) жрет немало CPU, особенно на серверах с большим количеством приложений (и ими вызываемых событий). Но тут, наверное, ничего не поделаешь.

Облачный мониторинг

Мониторинг умеет все тоже самое, что консольная утилита, по части сбора общесистемной информации. Помимо этого, клиент мониторинга детектит установленные на сервере приложения (в том числе и в контейнерах) и собирает по ним метрики, например статистику запросов (и время их выполнения) MySQL/Postgres, время отклика Nginx/HAProxy, состояние JVM, ну и так далее. Для значительного числа интеграций не требуется никакого ручного вмешательства, все начинает собираться автоматически. Есть куча predefined дашбордов и алертов, которые можно подкрутить под себя, при желании.

Также, клиент умеет собирать информацию об архитектуре микросервисов, запущенных поверх оркестраторов контейнеров (и красиво ее визуализировать), интегрироваться с AWS ECS, алертить в Slack/PagerDuty/VictorOps/OpsGenie.

Есть полноценный (с ограничением в 15 хостов) триал на две недели. Вполне достаточно, чтобы покрутить его со всех сторон и принять решение, насколько оно необходимо.

Есть, увы, и минусы. Основных претензий три:

Тяжелый клиент. В системных требованиях указано, что он может отъедать до 512MB RAM, 5-7% CPU, плюс генерирует весьма хороший сетевой трафик. Не знаю, насколько сильно это будет аффектить высоконагруженные сервера, но, думаю, это может быть заметно.
Веб-интерфейс - панель космолета. На странице информации о хосте показываются абсолютно все возможные интеграции и сервисы, даже те, которых и в помине нет на этом сервере. В итоге, на поиск нужной информации уходит довольно много времени. Хотелось бы переключатель, которые будет скрывать интеграции, по которым не приходит никаких данных.
Цена. 20-30$ за хост в месяц, на мой взгляд, ограничивают использование такого мониторинга большими серверами. Мониторить какой-нибудь K8S/DCOS-кластер из 5-7 здоровых машин такой штукой очень круто, а вот для россыпи мелких серверов выйдет очень накладно.

Выводы

Опенсорсную часть я водружу на все сервера, думаю. Очень удобная утилита для траблшутинга. А вот мониторинг пока стоит отложить до миграции в какой-нибудь K8S/DCOS, в текущем виде получается дороговато. Метрики приложений/системы можно пособирать и Prometheus’ом, а сложная контейнеризация у нас пока не используется. Но когда начнется плотная работа с контейнерами - sysdig окажется очень полезен.

Заметка о поездке в Москву

Thu, 17 Nov 2016 00:00:00 +0000

Цели

Вернулся с двухнедельной поездки в Москву. Путешествием я преследовал несколько целей:

Посмотреть на город и прикинуть, насколько он подходит мне для проживания;
Сходить на HighLoad++ 2016;
Познакомиться с коллективом, в котором работаю;
Познакомиться с ребятами из Express42 (Никита, спасибо за вискарь! Открою, когда в DevOps Deflope News будет 1000 человек);
Сменить обстановку и поработать какое-то время из офиса.

Цели я более-менее выполнил (жаль только, не всех увидел кого хотел), надо бы их осмыслить.

Москва как город для проживания

Плюсы

Все есть. Продукты, услуги, люди, развлечения, качество жизни и городской среды. Город, в котором я живу, имеет огромные проблемы со всем вышеперечисленным.
Больше возможностей для развития и обучения. Регулярные конференции, митапы, да и просто посиделки за пивом с беседами на технические темы.
Больше возможностей для карьерного роста. Моя удаленность от центра России и Европы (равно как и США) накладывает большие ограничения на выбор места работы. С другой стороны, в данный момент передо мной такой проблемы не стоит, я доволен своим текущим местом, интересных задач тут хватит еще надолго.
Больше возможностей для путешествий. У нас тут из адекватных (по цене и времени в пути) направлений только Китай и Корея, ну и Юго-Восточная Азия отчасти (Таиланд, Вьетнам). С Москвы доступна вся Европа, часть Африки и Азии, плюс до Таиланда лететь всего на час дольше.

Минусы

Огромные расстояния. Мой офис находился в 40 минутах езды на метро. По московским меркам близко, но эта каждодневное мотание туда-сюда меня адски вымотало. Много времени, много шума, много людей вокруг, я очень плохо все это воспринимаю. Моя девушка (мы вместе ездили) добиралась до своего места учебы по полтора часа в один конец, это еще хуже. Аналогично, если хочется куда-то выбраться - будь готов убить один или несколько часов времени на добирание. Ну или сиди в своем районе и довольствуйся тем, что здесь есть (а в пределах района часто есть абсолютно все что нужно).
Много людей. Не только в метро, но и на улицах, в различных заведениях и т.д. Аналогично, очень выматывает. Кому-то наверное наоборот в кайф быть в густонаселенных городах, но я не из их числа.
Быстрый ритм жизни. Собственно, расходы на перемещение вынуждают сокращать время на все остальное, начинаешь жить в мягком цейтноте.
Стоимость жизни. В целом, на продукты и базовые развлечения у нас уходило примерно столько же, сколько и в родном городе. Но жилье и услуги стоят намного дороже. Плюс постоянные траты на метро. Плюс богатство развлечений стимулирует тратить на них довольно много денег.
Погода. Отдельный ад. Я понимаю, что я приехал в неудачное время, но такая серость и слякоть - это кошмар. Целыми днями пасмурно (и я так понимаю - это стандартная картина для осени и весны), постоянный переменный то дождь, то снег, мрак. Да, значительно теплее, чем на ДВ, но и значительно слякотнее и сырее. Лучше уж мороз, чем каша под ногами. Выдержка из Википедии про Хабаровск (у нас сходный климат): “Количество солнечных дней в году существенно выше, чем во многих крупных городах России (до 300 дней в году; в Москве и Санкт-Петербурге — ок. 100)”.

Выводы

За две недели я очень сильно вымотался и понял что жить в Москве не хочу. Это надо либо очень постараться и найти квартиру недалеко от офиса/центра (и иметь очень хороший доход, чтобы ее оплачивать), либо работать дома и дальше своего района носа не высовывать. Так что наиболее вменяемым вариантом мне кажется переезд куда-то в не сильно большой город европейской части России (либо ближнего зарубежья), чтобы иметь возможность легко добраться до столицы, но не сталкиваться с ней каждодневно.

HighLoad++ 2016

Очень крутое мероприятие, хотя с непривычки было тяжело - постоянная толпа людей, да и вникать в доклады два дня подряд с утра до вечера непросто. Развиртуализировался с ребятами с Express 42, познакомился с Костей Назаровым, послушал про всякие интересные и не очень штуки. Понял, что навыки нетворкинга у меня никакие, надо над этим работать. :)

В целом, буду стараться ездить на подобные крупные мероприятия хотя бы раз в год. Полезно и с коллегами познакомиться, и встряхнуть свою голову, послушав как другие люди решают свои проблемы.

Как преобразовать один массив хэшей в другой

Mon, 03 Oct 2016 00:00:00 +0000

Задача

Есть в Ansible массив хэшей с данными о сервисах:

apps:
  - app_name: "app1"
    db_name: "db1" 
    db_owner: "own1"
    another_key: "somevalue"
  - app_name: "app2"
    db_name: "db2" 
    db_owner: "own2"
    another_key2: "somevalue2"

Я хочу этот массив преобразовать в другой, для того чтобы передать плейбуку для создания баз:

databases:
  - name: "db1" 
    owner: "own1"
  - name: "db2" 
    owner: "own2"

На голом Python это было бы легко, а вот с Jinja2 пришлось повозиться немного, в основном из-за постоянных истерик YAML на не нравящиеся ему скобочки да кавычки.

Итоговый код

pre_tasks:
  - name: set dict with postgresql bases
    set_fact: "postgres_bases={{ postgres_bases|default([]) + [{ 'name': item.db_name, 'owner': item.db_owner }] }}"
    with_items:  "{{ apps }}"

P.S. Дурацкий Jekyll сходит с ума от двойных фигурных скобок. :-/

Обратная совместимость модулей между Ansible 2.1 и Ansible 2.0

Sat, 03 Sep 2016 00:00:00 +0000

Вводная (TL;DR)

Столкнулся тут с неожиданно неприятным поведением Ansible, надо бы задокументировать опыт. В 2.1 изменился алгоритм обработки передаваемых модулю аргументов без явного указания типа. Если в 2.0 они передавались “как есть”, передали вы ему list или dict, так он таким и остался, то в 2.1 такие аргументы начали конвертироваться в строку. Вот коммит. Для передачи аргументов “как есть” ввели новый тип raw.

Проблема

Ничего не предвещало беды, я выкатывал новую версию приложения (хорошо хоть на тестовое окружение), Ansible отработал без ошибок. Но приложение не поднялось. Полезли с разработчиками на сервер, визуально все лежит на своих местах, в логах малоинформативные ошибки, дескать не могу загрузить такие-то модули (хотя они лежат на своих местах).

Наконец, через некоторое время, нашли проблему. Кусок json-конфига вместо

{
  "existing_key": ["first", "second"]
}

выглядел вот так (кавычки, обрамляющие список):

{
  "existing_key": "['first', 'second']"
}

Для работы с json у нас используется самописный модуль. Стало очевидно что дело в нем. Опытным путем установил, что под 2.0 он работал корректно, а под 2.1 подложил свинью.

Решение

Документация по написанию модулей для Ansible крайне бедна, поэтому почти сразу пришлось лезть в код класса AnsibleModule, что в ansible/lib/ansible/module_utils/basic.py. Выяснил изменения в преобразовании типов (что описано во вводной), добавил к нужному аргументу тип raw, под 2.1 все заработало корректно, зато сломалось в 2.0:

TASK [Patch JSON - add key] ****************************************************
fatal: [localhost]: FAILED! => {"changed": false, "failed": true, "msg": "implementation error: unknown type raw requested for value"}
        to retry, use: --limit @test.retry

Ломать совместимость не хотелось, поэтому в результате родился вот такой код:

def main():

    module = AnsibleModule(
        argument_spec=dict(
            value=dict(required=False, default=None)
        )
    )

    if 'raw' in module._CHECK_ARGUMENT_TYPES_DISPATCHER:
        module = AnsibleModule(
            argument_spec=dict(
                value=dict(required=False, default=None, type='raw'),
            )
        )

Проверяем, есть ли тип ⁠⁠⁠⁠raw⁠⁠⁠⁠ среди поддерживаемых, если есть, то переопределяем экземпляр класса ⁠⁠⁠⁠AnsibleModule⁠⁠⁠⁠ с ним.

Не знаю, насколько много людей затрагивает такая проблема, но в нашем случае это изменение в поведении оказалось критичным. Большинство, наверное, и так передают в модуль строки, в этом же случае нам надо передавать самые разные типы: строки, числа, массивы (мало ли что в json понадобится вставить) и преобразование в строку для всего ломает логику модуля.

Краткое сравнение систем оркестрации контейнеров

Sun, 21 Aug 2016 00:00:00 +0000

Информация актуальна где-то на конец июля.

Вынесу сюда краткое summary по исследованию существующих систем оркестрации в формате “плюсы и минусы”, сделанному мной на стажировке в Экспресс42. В статью не вошла связка Mesos+Marathon, т.к. ее ставил не я, но остальное вроде все охватил. Статейка больше для себя, чтоб иметь краткое описание систем в одном месте.

Fleet

Fleet очень круто сделан идеологически - ты работаешь с целым кластером как с обычной системой, описывая обычные, в общем-то, юнит-файлы для systemd. В части эксплуатации лишних сущностей минимум, все они скрыты под капотом, под который лезть приходится не очень часто. Но с другой стороны, эта скрытость вызывает проблемы с пониманием логики системы, когда тебе надо не просто бездумно шлепать по мануалу, а делать что-то свое. Также, fleet бедноват на средства работы со сложными системами, у него урезанные зависимости, нет иерархий, окружений.

Есть constraints (как на уровне “запусти на ноде с такими-то свойствами”, так и на уровне “запусти/не запускай сервис2 на ноде с сервис1”)
Нет healthchecks ни в каком виде
Есть нормальный DNS Service Discovery, хоть и за счет внешних сервисов
Удобный способ описания всего кластера в одном файле cloud-init
Зависимости есть, но в очень урезанном виде: они работают только в пределах одной ноды. То есть мы можем запустить Сервис2 после Сервиса1, но только если оба этих сервиса запущены на одной ноде. Более сложные зависимости будут “когда-нибудь”
Есть изолированная оверлейная сеть, с которой легко вытащить контейнер наружу, при желании (через --net=host)
Поддерживается все множество docker-команд в юнитах
По файлу на сервис. Намного удобнее, чем отслеживать изменения в огромном файле на несколько сотен строк.
Сложно делать blue-green потому что сложно развернуть две инфраструктуры в пределах одного кластера. Неудобно делать partial deploy
Зато rolling довольно безопасен за счет большого количества стадий. Хотя средств отката я не увидел, придется какой-то внешней системой назад катить
Простой синтаксис. Ребята не изобретали свой формат, а взяли обычный systemd синтаксис.

Nomad

В Nomad есть то, чего нет в Docker - описание инфраструктуры в едином файле, healthchecks в том же описании, dry-run, но зато не хватает всего остального: нет нормальной работы ни с сетью, ни с персистентными данными. Для эксплуатации в наших условиях как-то совсем не годится.

Важно: до сих пор нет поддержки Docker volumes! - https://github.com/hashicorp/nomad/issues/150 https://github.com/hashicorp/nomad/issues/62
Важно: Номад не рестартит контейнеры с проваленными healthcheck. Просто помечает их в консуле как failed, но не перезапускает - https://github.com/hashicorp/nomad/issues/876
Нельзя рестартануть таску через nomad cli. Надо идти на слейв и прибивать контейнер руками.
Файл получается довольно объемный из-за JSON-подобного синтаксиса. Скобки-скобки-скобки. Но вполне читаемый.
Номад не умеет в зависимости между сервисами, когда-нибудь обещают сделать - https://github.com/hashicorp/nomad/issues/419
Номад не умеет биндить порты на все интерфейсы или на какой-то определенный для контейнера. Только на тот, который указан в параметре network_interface конфига слейва. Обещают пофиксить когда-нибудь - https://github.com/hashicorp/nomad/issues/646
Зато healthcheck’и можно описывать прямо тут, что удобно. Поддерживаются http, tcp и script чеки.
Некрасивые DNS-имена. Мало того что надо извращаться с dnsmasq/bind для того чтобы пробросить DNS консула на 53 порт, так еще и имена получаются некрасивые, по типу datastore-zookeeper.service.consul, вместо более цивильных zookeeper.datastore.service.consul
Можно передавать данные о private registry прямо в самом файле, удобно.
Нет способов исключить повторяемость кода. Надо тебе передавать одни и те же переменные в 10 разных контейнеров - дублируй код 10 раз.
Nomad умеет обновлять джобу через скармливание ему новой версии hcl-файла, при этом обновляя контейнеры с заданными интервалами и параллелизмом.
Поддерживается dry-run режим запуска джобы.

Kubernetes

Kubernetes очень крутой, но документация, особенно для такой объемной и сложной системы, просто ужасна. Мануалы часто неактуальны, некоторые вещи вообще в ней отсутствуют и приходится рыться в огромных обсуждениях на Github. А так - в нем есть почти все, хоть и местами через жопу.

Есть constraints, healthchecks, DNS Service Discovery, scaling, autoscaling, single tasks, rolling updates, кофеварка и триммер для волос в носу;
Есть cli утилита, которая может работать через TLS;
Есть какие-то политики безопасности, но я их не трогал. Вроде как можно авторизовать пользователей по ключу и позволять им разное;
Есть богатые возможности по определению своих метаданных для сервисов/подов/и т.д. Очень удобно в больших инфраструктурах;
Есть API, документировано тоже не прям супер;
Есть красивенький Dashboard
Нет cron tasks, но есть четкий milestone, когда их запилят - в следующей версии
Удобный способ описания всего кластера в одном файле cloud-init
Удобный способ дистрибуции всего кластерного добра в контейнере, все развертывание сводится к указанию этому контейнеру нужных ключей
Есть изолированная оверлейная сеть, с которой можно вытащить контейнер наружу, при желании через load balancer
Есть поддержка распределенных/сетевых ФС из коробки;
По умолчанию все довольно сильно изолировано, как на уровне namespace’ов, так и вообще by design. С другой стороны - зато сложновато взаимодействие сервисов настраивать;
Очень много сущностей на всех уровнях. Kubectl имеет довольно длинные команды (хотя есть completions). Искренне не понимаю, зачем нужно было городить 4 сущности: Pod, Service, ReplicaSet, Deployment там, где другие системы обходятся одной;
Как следствие из предыдущего - очень многословные yaml-файлы. Описание 4 сервисов у меня заняло 300 строк там, где в Swarm можно было бы обойтись 4 командами;
Помимо количества сущностей, они еще и плохо документированы. Ладно бы еще документация местами отсутствовала и приходилось лезть на Github, так она просто неправильная и неактуальная. Ты видишь мануал на официальном сайте, который призван решить твою проблему, а он неточный и устаревший. В итоге ты убиваешь кучу времени на этот мануал, а потом все равно в итоге лезешь на Github.

Swarm

Мне оркестрация от Docker’а очень понравилась. Реально не хватает только описания инфраструктуры как кода где-нибудь в одном файле, с зависимостями и переменными. А так: кластер развертывается быстро, никаких непонятных дополнительных сущностей, есть приватные сети, есть общие сети, есть балансировка, скейлинг, constraints, вот это вот все. Учитывая темпы развития Docker - все скоро будет совсем хорошо.

Aurora

Aurora не умеет запускать несколько джобов с зависимостями между ними (например, запусти zk, как только он запустится - запусти kafka и т.д.). Одновременно, впрочем, она тоже не умеет их запускать, только по одному за раз. http://mail-archives.apache.org/mod_mbox/aurora-user/201602.mbox/%3CEE9100CC-04FF-4C64-B479-D3DF68D8C0BE%40lensa.com%3E - тут и далее по треду предлагают городить свои скрипты или использовать что-то вроде Chronos или Airflow.
constraints работают на уровне параметра attributes mesos-slave. Т.е. определяем на слейве какие-то атрибуты и потом можем сказать авроре - запускай такой-то джоб только на слейве с таким-то атрибутом.
Healthchecks есть, http и shell, но я их не тестил еще.
Максимальное количество failures, timeout между попытками перезапуска есть.
Внутри aurora-файла полноценный питон, можно определять какие-то структуры, подсовывать их в таски, стрелять себе в ногу из револьвера, ружья, дробовика, пулемета. Мне оказалось удобно определить dict со всеми параметрами в шапке файла и обращаться к нему по ходу дела.
Целиком игнорируются ENV, ENTRYPOINT и COMMAND докерфайла. С одной стороны это плюс, можно один и тот же контейнер переиспользовать для разных тасок, плюс в ряде случаев можно обойтись и без пересборки контейнеров. С другой стороны - приходится все эти переменные и команды вытаскивать из докерфайла в аврорафайл, получается что-то вроде:

postgres_proc = env_proc(
   name="postgres_daemon",
   cmdline="""
       export PGDATA='/pgdata'
       export PG_MAJOR='9.3'
       export PG_VERSION='9.3.13-1.pgdg80+1'
       export PATH="/usr/lib/postgresql/$PG_MAJOR/bin:$PATH"
       /docker-entrypoint.sh postgres
   """

Есть cronjobs, services (long-running jobs) и обычные “одноразовые” джобы. С учетом предыдущего пункта все три вида можно построить на базе одного контейнера, переопределяя cmdline.
Через aurora-cli можно логиниться прямо в контейнер джобы и чего-нибудь херачить там руками.

Заметка о стажировке в Экспресс42

Mon, 15 Aug 2016 00:00:00 +0000

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

Вкратце: с обычного офисного админа в небольшом городе, занимающегося всем, от протяжки сети и ползания под столами пользователей до попыток изучения современных средств администрирования, типа Ansible и Docker, я дорос до более-менее уверенного devops-специалиста, работающего с московскими компаниями.

Честно говоря, я думал что вхождение в индустрию будет намного более долгим и болезненным. Наверное, стоит сказать спасибо кризису, если б не он, то мое прошлое место работы (то самое, где я работал офисным админом) не начало бы загибаться, я так бы и изучал все потихоньку в свободное время и раскачался на бы смену работы только через пару лет. Но тут в конторе начались проблемы, началось урезание бюджетов, сокращения (на момент моего ухода оттуда из 7 айтишников осталось лишь двое, при не сильно уменьшившейся инфраструктуре) и требования сделать хорошо из говна и палок.

Естественно, корявые решения проблем порождали новые проблемы, развития становилось все меньше, тушения пожаров все больше и где-то с января-февраля я начал интенсивно искать новую работу. Тут стоит отметить, что ИТ-сфера у нас в городе развита крайне плохо и я работал в одной из самых продвинутых в этом плане компаний, которая хоть и не занималась непосредственно ИТ-бизнесом (а была просто сетью магазинов мебели и стройматериалов), но хотя бы имела отлаженные процессы и понимание значимости ИТ в современном бизнесе. В итоге, в городе у меня, фактически, было всего два пути: идти к какому-нибудь провайдеру, либо идти на какой-нибудь завод. Ни тот, ни другой вариант меня не устраивал.

Другой вариант - идти во фриланс - мне тоже не сильно нравился, и я держал его на самый крайний случай. У меня был неплохой приработок на Upwork, при занятости 10-12 часов в неделю я получал почти столько же, сколько в офисе, но основным источником дохода делать я его не хотел. Причин этому три. Первая: отсутствие роста, я бы засел в своей нише LAMP/LEMP-админа и мне было бы тяжело с нее выбираться. На фоне нынешнего сокращения роли “олдскульных” админов это виделось мне тупиковым путем. Вторая причина: слишком длинная цепочка между заказчиком и исполнителем, любая проблема в этой цепочке могла оставить меня без денег или без наработанной репутации. Проблемы с аккаунтом на Upwork, проблемы с Paypal/Payoneer, проблемы с картой, какие-нибудь поправки в законодательстве, затрудняющие получение денег из-за рубежа - и все, швах. В итоге, кстати говоря, так и вышло, и я окончательно отказался от работы на Upwork: Payoneer три месяца не мог прислать мне карту, Upwork отобрал у меня Top Rated статус (послали мне письмо с требованием перепройти верификацию, которое я не получил и они просто молча забрали у меня статус), плюс все эти новости о падении капитализации Upwork и куча новых дополнительных комиссий окончательно разрушили мое доверие к этому сервису. Ну и третья проблема - необходимость постоянного поиска клиентов, ты, условно говоря, три часа работаешь, и еще три часа ищешь, договариваешься, продаешь себя. Мне это не нравится и очень утомляет.

Уехать из города куда-нибудь в центральную часть России я пока не могу по личным причинам, так что у меня оставался только один вариант - full-time удаленная работа. Для зарубежного рынка я чувствовал себя не слишком уверенно, хотя ради пробы даже собеседовался в один французский стартап, так что где-то с начала марта стал искать вакансии по России. Целенаправленно искал вакансии для джуниоров, т.к. у меня не было понимания своего уровня относительно требований рынка и относительно других специалистов.

К тому времени я уже довольно активно учился на Хекслете, так что отправил резюме в Hexlet-source (но получил отказ), записался на публичное собеседование (но из-за проблем с поиском собеседующих прошел его только в начале мая). Где-то в середине марта в твиттере Кирилла Мокевнина я увидел вакансию на должность devops-инженера в Express42 и решил попробовать по принципу “ну, за спрос денег не берут”. Вообще, про эту вакансию я слышал еще в феврале в подкасте Devops Deflope (его как раз ведут ребята из Экспресса), но тогда не уделил ей особого внимания. Сейчас же, на мой взгляд, она подходила мне идеально - за трехмесячную стажировку меня обещали обучить devops-тулсету, да еще и платили за это неплохую, по меркам моего города, стипендию.

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

График был примерно такой: я сдвинул свой рабочий день где-то на 3 часа вперед, так чтобы иметь окно коммуникации с 17:00 до 20:00-20:30 (с 10:00 до 13:00 по Москве), соответственно, все занятия, которые проводились с остальными стажерами в офисе утром - для меня были вечером. Проблем с изменением рабочего графика не возникло, продуктивность не пострадала, даже скорее наоборот - активное время увеличилось с 8 до 11 часов, что позволяло более гибко планировать день.

По самому обучению - все очень круто. Начали с азов, с лекций и практических заданий (Docker, Chef, Ansible, Jenkins), потом переключились на реальные задачи. К концу стажировки я самостоятельно успешно возился с собственным тестовым кластером Kubernetes, занимаясь сравнительным исследованием актуальных систем оркестрации контейнеров. Была возможность поучаствовать и в opensource разработках, и в жизни комьюнити (я вот, например, занялся постингом новостей в Telegram-канал DevOps Deflope News и планирую продолжать это и дальше). В Экспресс42 очень сильная инженерная культура, внутренние митапы, презентации, взаимопомощь. Были созданы все условия для обучения и развития, даже с поправкой на то, что я общался с командой всего 3 часа в день.

К сожалению, после окончания стажировки, продолжить работу в Экспресс42 не получилось - вся команда и вся работа сосредоточена в Москве и нормально взаимодействовать с клиентами с моей разницей во времени было бы очень проблематично. Тем не менее, ребята порекомендовали меня в другую команду, куда я успешно прошел собеседование (рекордные полтора часа от “здравствуйте, мне тут сказали вы ищете работу” до “поздравляем, вы приняты”) и с сегодняшнего дня приступаю к работе. Команда полностью распределенная, задачи интересные, так что фана, думаю, будет еще больше чем на стажировке.

Вообще, главный вывод для себя я сделал такой: надо пытаться устроиться на интересную тебе работу даже если боишься что не дотянешь по навыкам. Если есть желание и способность учиться - то дотянешь. Ну и для людей с небольших городов - remote-рынок сейчас бурно растет, вполне можно найти работу в Москве, сидя в Хабаровском крае. :)

Как установить плагин в Roundcube

Tue, 23 Feb 2016 00:00:00 +0000

Задача нетривиальная для пользователей, как ни странно.

Плагины ставятся с помощью composer – менеджера зависимостей для PHP. То есть, фактически, мы просто добавляем к текущей инсталляции Roundcube новую зависимость.

Для начала, перейдем в директорию Roundcube и установим сам composer:

cd /var/www/roundcube
curl -s https://getcomposer.org/installer | php

Скопируем шаблон конфига композера для Roundcube и откроем его для редактирования:

cp composer.json-dist composer.json
vim composer.json

Идем в https://plugins.roundcube.net/, ищем там нужный нам плагин, например https://plugins.roundcube.net/packages/roundcube/filters, добавляем строчку из описания плагина, следующую после require (например require: "roundcube/filters": "dev-master") в секцию require нашего composer.json. В итоге она начинает выглядеть так (не забываем про запятые):

    "require": {
        "php": ">=5.3.7",
        "roundcube/plugin-installer": "~0.1.6",
        "pear-pear.php.net/auth_sasl": "~1.0.6",
        "pear-pear.php.net/net_idna2": "~0.1.1",
        "pear-pear.php.net/mail_mime": "~1.10.0",
        "pear-pear.php.net/net_smtp": "~1.7.1",
        "pear-pear.php.net/crypt_gpg": "~1.4.0",
        "roundcube/net_sieve": "~1.5.0",
        "roundcube/filters": "dev-master"
    },

Сохраняем файл, закрываем редактор, запускаем установку зависимостей: php composer.phar install

Композер выкачивает их, собирает, устанавливает, и т.д. По окончанию процесса он предложит добавить плагины в config/config.inc.php автоматически. Если не хотите, то можно сделать это вручную, добавив название плагина в параметр $config['plugins'] в config/config.inc.php:

$config['plugins'] = array(
        'acl',
        'jqueryui',
        'filters',
);

Неприятный момент. Если вы используете PHP 5.3 (который как бы нормально поддерживается Roundcube), то ничерта у вас не соберется со стандартным composer.phar. Причина – net_smtp последней версии (1.7.1 на данный момент) требует PHP не ниже 5.4.0. Выход: заменить строчку

"pear-pear.php.net/net_smtp": "~1.7.1",

на

"pear-pear.php.net/net_smtp": "~1.6.3",

Ну или обновиться до PHP 5.4+, т.к. 5.3 уже не поддерживается уже почти два года (5.4, впрочем, тоже).

Полезные ссылки:

Как избавиться от WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! при работе с Vagrant

Wed, 20 Jan 2016 00:00:00 +0000

При разработке и тестировании часто приходится пересоздавать Vagrant-машину с нуля. Так как айпишник у нее не меняется, после пересоздания машины и при попытке к ней зацепиться мы получаем истерику от SSH:

$ ssh root@192.168.99.99
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
9f:56:58:8c:08:bc:1a:b1:3f:fa:c8:2e:0a:97:6d:19.
Please contact your system administrator.
Add correct host key in /home/strangeman/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/strangeman/.ssh/known_hosts:340
 remove with: ssh-keygen -f "/home/strangeman/.ssh/known_hosts" -R 192.168.99.99
ECDSA host key for 192.168.99.99 has changed and you have requested strict checking.
Host key verification failed.

Решается эта проблема просто: мы начинаем использовать /dev/null для хранения KnownHosts и отключаем строгую проверку ключа. Естественно, в целях безопасности, стоит это делать только для IP ваших Vagrant-машин (я, например, использую 192.168.99.0/24). Добавляем в начало ~/.ssh/config следующие строки:

Host 192.168.99.*
 StrictHostKeyChecking no
 UserKnownHostsFile=/dev/null

Полезные команды, которые я постоянно забываю

Fri, 01 Jan 2016 00:00:00 +0000

Tar & Mysql backup

Tar a directory

tar czf name_of_archive_file.tar.gz name_of_directory_to_tar

Gzip mysql dump

mysqldump admin_sdfsdf -u admin_sgerfgdfg -p | gzip > mysql.tar.gz

Untar a directory

tar -zxvf ../tmp/site.tar.gz .

Unzip mysql dump

zcat ../tmp/mysql.tar.gz | mysql sdfsdfsdf -u sdfsdfsdfsdfsf -p

Docker

Delete all containers

docker ps -aq | xargs docker rm -f

Delete all untagged images

docker images | grep "<none>" && docker rmi -f $(docker images | grep "<none>" | awk "{print \$3}")

Kill all java containers

docker ps | grep "java -" | cut -f 1 -d ' ' | xargs -n1 docker kill

systemd

Restart all failed units

systemctl list-units --state=failed | grep ● | cut -f 2 -d ' ' |  xargs -n1 systemctl restart

Типовой конфиг сайта на связке NGINX + PHP-FPM

Sun, 25 Oct 2015 00:00:00 +0000

Пути файлов в зависимости от ОС, версии ОС и используемого софта (web-панели типа WHM или Parallels Plesk) могут очень сильно варьироваться, поэтому я их тут не указываю. Опции, в зависимости от конкретного сайта и сервера (особенно это касается PHP-FPM: используемого process manager и его настроек) также могут варьироваться в широких пределах. Здесь приведен более-менее дефолтный конфиг, с которым все должно “просто работать”, а производительность сервера можно тюнить уже потом.

Установки я не касаюсь ровно по той же причине. Если с nginx чаще всего все довольно просто, то с PHP-FPM каждый случай индивидуален в зависимости от используемого софта.

NGINX Vhost

Возможные пути:

/etc/nginx/sites-enabled/example.conf
/etc/nginx/conf.d/example.conf
/etc/nginx/conf/example.conf
/etc/nginx/plesk.conf.d/vhosts/example.conf

можно попробовать посмотреть командой nginx -V, флаг --conf-path, затем уже смотреть инклуды в основном конфиге.

server {
    listen 80;

    root /srv/example.com;
    server_name example.com;

    error_log /var/log/nginx/example.com.error_log;
    access_log /var/log/nginx/example.com.access_log;

    index index.php;

    location = /favicon.ico {
   log_not_found off;
            access_log off;
    }

    location = /robots.txt {
            allow all;
            log_not_found off;
            access_log off;
    }

    location / {
            # This is cool because no php is touched for static content.
            # include the "?$args" part so non-default permalinks doesn't break when using query string
            try_files $uri $uri/ /index.php?$args;

    }

    location ~ \.php$ {
         # Filter out arbitrary code execution
        location       ~ \..*/.*\.php$ {return 404;}

        fastcgi_index index.php;
        include        fastcgi_params;
                fastcgi_pass unix:/var/run/php5-fpm.example.sock;
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
    }

    location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ {
            expires max;
            log_not_found off;
    }
}

PHP-FPM pool definition

Возможные пути:

/etc/php5/fpm/pool.d/example.conf
/etc/php-fpm/pool.d/example.conf
/etc/php5-fpm/pool.d/example.conf
/usr/local/etc/php-fpm.conf
/usr/local/etc/php5/fpm/pool.d/example.conf

; Start a new pool named 'example'.
; the variable $pool can we used in any directive and will be replaced by the
; pool name ('example' here)
[example]

; Unix user/group of processes
; Note: The user is mandatory. If the group is not set, the default user's group
;   will be used.
user = www-data
group = www-data

listen = /var/run/php5-fpm.example.sock

listen.owner = www-data
listen.group = www-data

pm = ondemand
pm.max_children = 20

; Chdir to this directory at the start.
; Note: relative path can be used.
; Default Value: current directory or / when chroot
chdir = /

Автоматическая настройка Nginx+PHP-FPM в VestaCP

Tue, 20 Oct 2015 00:00:00 +0000

Неактуально по причине выхода новой Весты, которая поддерживает PHP-FPM из коробки.

Пререквизиты:

Ubuntu 14.04
VestaCP 0.9.8

Хочется, чтобы при добавлении домена через веб-морду VestaCP автоматически создавался пул PHP-FPM.

TODO: Реализовать удаление пула из конфига при удалении домена. :)

For nginx

Основано вот на этом: https://github.com/autronix/Vesta-0.9.8-with-nginx-only

Но я внес кое-какие правки под себя:

# cat /usr/local/vesta/data/templates/web/nginx/default.tpl

server {
    listen      %proxy_port%;
    server_name %domain_idn% %alias_idn%;
    error_log  /var/log/apache2/domains/%domain%.error.log error;

    root           %docroot%;
    index index.php index.html index.htm;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    include %home%/%user%/conf/web/nginx.%domain%.conf*;

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass  unix:/var/run/php5-fpm.%domain_idn%.sock;
        fastcgi_index index.php;
        include fastcgi_params;
    }

    location ~ /\.ht    {return 404;}
    location ~ /\.svn/  {return 404;}
    location ~ /\.git/  {return 404;}
    location ~ /\.hg/   {return 404;}
    location ~ /\.bzr/  {return 404;}

}

# cat /usr/local/vesta/data/templates/web/nginx/default.stpl

server {
    listen      %proxy_ssl_port%;
    server_name %domain_idn% %alias_idn%;
    ssl         on;
    ssl_certificate      %ssl_pem%;
    ssl_certificate_key  %ssl_key%;
    error_log  /var/log/apache2/domains/%domain%.error.log error;

    root           %docroot%;
    index index.php index.html index.htm;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    include %home%/%user%/conf/web/nginx.%domain%.conf*;

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass  unix:/var/run/php5-fpm.%domain_idn%.sock;
        fastcgi_index index.php;
        include fastcgi_params;
    }

    location ~ /\.ht    {return 404;}
    location ~ /\.svn/  {return 404;}
    location ~ /\.git/  {return 404;}
    location ~ /\.hg/   {return 404;}
    location ~ /\.bzr/  {return 404;}

}

For PHP-FPM

Устанавливаем php5-fpm

apt install php5-fpm

Прописываем, где искать инклуды конфигов:

# tail -n 1 /etc/php5/fpm/php-fpm.conf
include=/home/*/conf/web/php_pool.conf

Прописываем шаблон для конфига:

# cat /usr/local/vesta/data/templates/web/nginx/phpfpm.tpl
 
[%domain_idn%]
 
user = %user%
group = %group%
 
listen = /var/run/php5-fpm.$pool.sock
 
listen.owner = %user%
listen.group = %group%
;listen.mode = 0660
 
; Choose how the process manager will control the number of child processes.
; Possible Values:
;   static  - a fixed number (pm.max_children) of child processes;
;   dynamic - the number of child processes are set dynamically based on the
;             following directives. With this process management, there will be
;             always at least 1 children.
;             pm.max_children      - the maximum number of children that can
;                                    be alive at the same time.
;             pm.start_servers     - the number of children created on startup.
;             pm.min_spare_servers - the minimum number of children in 'idle'
;                                    state (waiting to process). If the number
;                                    of 'idle' processes is less than this
;                                    number then some children will be created.
;             pm.max_spare_servers - the maximum number of children in 'idle'
;                                    state (waiting to process). If the number
;                                    of 'idle' processes is greater than this
;                                    number then some children will be killed.
;  ondemand - no children are created at startup. Children will be forked when
;             new requests will connect. The following parameter are used:
;             pm.max_children           - the maximum number of children that
;                                         can be alive at the same time.
;             pm.process_idle_timeout   - The number of seconds after which
;                                         an idle process will be killed.
; Note: This value is mandatory.
pm = ondemand
 
pm.max_children = 20
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
pm.process_idle_timeout = 10s
pm.max_requests = 500

Вносим правку в скрипт Vesta CP для добавления нового веб-прокси

# diff -p /usr/local/vesta/bin/v-add-web-domain-proxy /usr/local/vesta_fixed/bin/v-add-web-domain-proxy -c5
*** /usr/local/vesta/bin/v-add-web-domain-proxy    2015-06-05 02:00:50.000000000 +1000
--- /usr/local/vesta_fixed/bin/v-add-web-domain-proxy    2015-10-15 10:45:52.162316790 +1000
*************** if [ "$SSL" = 'yes' ]; then
*** 84,93 ****
--- 84,100 ----
      if [ -z "$(grep "$conf" $proxy_conf)" ]; then
          echo "include $conf;"&gt;&gt; $proxy_conf
      fi
  fi
 
+ # Add PHP-fpm pool
+ tpl_file="$WEBTPL/$PROXY_SYSTEM/phpfpm.tpl"
+ conf="$HOMEDIR/$user/conf/web/php_pool.conf"
+ add_web_config
+ service php5-fpm restart
+
+
  # Running template trigger
  if [ -x $WEBTPL/$PROXY_SYSTEM/$template.sh ]; then
      $WEBTPL/$PROXY_SYSTEM/$template.sh $user $domain $ip $HOMEDIR $docroot
  fi

Важный нюанс: sock-файл для общения между Nginx и PHP-FPM у нас создается с правами 0660 от имени пользователя. Соответственно Nginx должен запускаться от пользователя, состоящего в той же группе, что и пользователь (ну или наоборот, пользователь должен быть быть в группе nginx).

Собственно все. Рестартим Vesta, Nginx, PHP-FPM, добавляем новый домен через веб-морду, проверяем.

service vesta restart
service php5-fpm restart
service nginx restart

Markdown Cheatsheet

Thu, 01 Jan 1970 00:00:00 +0000

This is Markdown Cheatsheet Demo for Thinkspace, this Jekyll theme. Please check the raw content of this file for the markdown usage.

Typography Elements in One

Let’s start with a informative paragraph. This text is bolded. But not this one! How about italic text? Cool right? Ok, let’s combine them together. Yeah, that’s right! I have code to highlight, so ThisIsMyCode(). What a nice! Good people will hyperlink away, so here we go or http://www.example.com.

Headings H1 to H6

H1 Heading

H2 Heading

H3 Heading

H4 Heading

H5 Heading

H6 Heading

Footnote

Let’s say you have text that you want to refer with a footnote, you can do that too! This is an example for the footnote number one [¹]. You can even add more footnotes, with link! [²]

Blockquote

Start by doing what’s necessary; then do what’s possible; and suddenly you are doing the impossible. –Francis of Assisi

NOTE: This theme does NOT support nested blockquotes.

List Items

First order list item
Second item

Unordered list can use asterisks
Or minuses
Or pluses

Code Blocks

var s = "JavaScript syntax highlighting";
alert(s);

s = "Python syntax highlighting"
print s

No language indicated, so no syntax highlighting.
But let's throw in a <b>tag</b>.

Table

Table 1: With Alignment

Tables	Are	Cool
col 3 is	right-aligned	$1600
col 2 is	centered	$12
zebra stripes	are neat	$1

Table 2: With Typography Elements

Markdown	Less	Pretty
Still	`renders`	nicely
1	2	3

Horizontal Line

The HTML <hr> element is for creating a “thematic break” between paragraph-level elements. In markdown, you can create a <hr> with any of the following:

___: three consecutive underscores
---: three consecutive dashes
***: three consecutive asterisks

renders to:

Media

YouTube Embedded Iframe

Image

Footnote:

1: Footnote number one yeah baby! ↩
2: A footnote you can link to - click here! ↩

Tech notes

How to Hide Modal App Behind Cloudflare Zero Trust

Why you might need this

Downsides

Prerequisites

Algorithm

How it works

CI/CD for Deploying Flows in Prefect Cloud 2

Initial Requirements

What Prefect Offers

Description of Deployment Infrastructure

Conclusion

Как сдампить существующую инфраструктуру в AWS в виде кода

Вводная

Алгоритм

Известные проблемы

Тулинг для миграции уже созданной инфраструктуры в Terraform

terraform import

terraformer

k2tf и tfk8s

tfautomv

Как я новую работу искал

Источник

Как превратить кастомный запрос ClickHouse в метрики для Prometheus

Источник

Edit all sentry projects with curl, jq and duct tape

Script

Итоги 2018 года

Минусы

Плюсы

Планы

Yet another 'How to speed up Ansible' tips

SSH settings

Facts caching

Profiling

Анонимизация данных в PostgreSQL базе с помощью Python

Table Of Contents

Постановка задачи

Популярные библиотеки

Реализация

Benchmarking Python vs Go+Python vs Rust+Python for Vincenty formula

Table Of Contents

Benchmarking Python vs Go+Python vs Rust+Python

Disclaimer

Environment and tools

OS

Languages

Benchmarking

How to run it

Results

Size of binaries

Some additional thoughts

Kafka operation tips

Table Of Contents

How to increase topic Replication Factor in Kafka

How to look current topic configuration

How to change topic Replication Factor

How to increase partition count

How to fix ‘Leader: -1’ for Kafka partition

How it looks like

How to fix it

Ansible-Semaphore UI Walkthrough

Table Of Contents

Introduction

UI Walkthrough

Login Page

Main Page

Global User List

Global User Edit Dialog

Main Project Page

Project Settings Page

Task Templates Page

Task Template Edit Page

Inventory Page

Key List and Key Edit Pages

Repository List Page

Project Team Page and Add Project User Dialog

Task Launch Process

Впечатления от системы мониторинга Sysdig

Общая информация