🔥 Как ускорить docker build и сократить размер образа

Иногда docker build тянется вечность, а итоговый образ весит больше, чем база данных 🐘. Разбираемся, как ускорить сборку и оптимизировать размер образа без потери функциональности.


1. Используй multistage build
Разделяй стадии сборки и финальный образ. Это особенно важно при компиляции (Go, Java, Node.js):

# Стадия 1: билд
FROM golang:1.20 as builder
WORKDIR /app
COPY . .
RUN go build -o app

# Стадия 2: минимальный runtime
FROM alpine:latest
COPY --from=builder /app/app /usr/local/bin/app
ENTRYPOINT ["app"]

Образ получается меньше 10 МБ!


2. Минимизируй base image
Используй alpine, distroless, scratch, если не нужен полноценный дистрибутив:

FROM python:3.12-slim

Или вообще:

FROM scratch

3. Правильно расставляй COPY и RUN
Кешируй слои — сначала зависимости, потом исходники:

COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .

Так pip install не будет повторяться при каждом изменении исходников.


4. Убирай мусор и временные файлы
После установки пакетов — чисти кэш:

RUN apt-get update && apt-get install -y ... \
 && rm -rf /var/lib/apt/lists/*

5. Используй .dockerignore
Иначе в билд попадут node_modules, .git, логи и прочее:

.git
node_modules
*.log

Вывод:
Минимизация образа — это не только про размер, но и про безопасность (меньше surface area), скорость CI/CD, стабильность. И не забывай — docker build тоже надо профилировать.

#devops #docker #ci #optimization

Подпишись 👉 @i_DevOps

🔥 Ускоряем сборку Docker-образов: слои и кэш — наши друзья

Когда сборка Dockerfile занимает минуты — это мешает dev-loop'у. А ведь можно сильно ускориться с парой простых правил 👇


🧠 Основные принципы ускорения:

1. Максимально используем кэш
Docker кэширует каждый слой. Если слой не изменился — пересобирать не будет.

➤ Сначала COPY зависимости, потом остальной код:

   COPY requirements.txt .
   RUN pip install -r requirements.txt  # кэшируется

   COPY . .  # некэшируемо при любом изменении в коде
   

2. Объединяем RUN-команды
Меньше слоёв — быстрее сборка и push:

   RUN apt update && apt install -y curl git \
       && rm -rf /var/lib/apt/lists/*
   

3. .dockerignore
Убедись, что не копируешь лишние файлы (например, .git/, tests/, node_modules/):

   .git
   node_modules
   *.log
   __pycache__/
   

4. Меньше COPY, больше multi-stage
Разделяй сборку и runtime — не таскай компиляторы в прод:

   FROM golang:1.20 AS builder
   WORKDIR /app
   COPY . .
   RUN go build -o app

   FROM debian:bullseye-slim
   COPY --from=builder /app/app /usr/bin/app
   CMD ["app"]
   

5. Кэшируй pip/npm/go-пакеты
→ в Dockerfile сначала копируй файл зависимостей, ставь пакеты, только потом — весь код проекта.


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


#devops #девопс

Подпишись 👉@i_DevOps

🔥 Как ускорить GitHub Actions на 40% и платить меньше

CI — это не место для медлительности. Особенно когда билд идёт 15 минут, а запусков в день — сотни. Сейчас разберём, как оптимизировать GitHub Actions: быстрее, дешевле, эффективнее.


🔹 1. Используйте actions/cache правильно
Загрузка и компиляция зависимостей — одно из самых дорогих мест. Добавьте кэширование для npm, pip, go mod, docker layers. Пример для Node.js:

- uses: actions/cache@v3
  with:
    path: ~/.npm
    key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-npm-

⚠️ Не кэшируйте build-артефакты, которые зависят от среды (OS, runner version) — это приведёт к нестабильности.


🔹 2. Job matrix + fail-fast: false = контроль над параллелизмом
Matrix позволяет запускать тесты параллельно (например, разные версии Python), а fail-fast: false не останавливает все джобы при первом фейле.

strategy:
  fail-fast: false
  matrix:
    python-version: [3.8, 3.9, 3.10]

🔹 3. Разделяйте пайплайн на reusable workflows
Выносите повторяющуюся логику в .github/workflows/reusable.yml и вызывайте с параметрами. Это уменьшает дублирование и ускоряет поддержку.

- uses: ./.github/workflows/reusable.yml
  with:
    env: staging

🔹 4. Используйте self-hosted runners, если билд тяжёлый
Если у вас сборка Docker-образов весит десятки минут — дешевле и быстрее поднять свои раннеры в EC2 или Kubernetes (особенно с GPU или кастомной средой).

📌 Попробуйте actions-runner-controller для Kubernetes:
https://github.com/actions/actions-runner-controller


🔹 5. Откажитесь от setup-* при каждом запуске
setup-node, setup-go, setup-java — удобны, но каждый раз качают и устанавливают SDK. Замените на preinstalled версии в раннерах или кэшируйте вручную.


✅ Вывод:
Оптимизация GitHub Actions — это про кэш, параллельность и минимизацию накладных расходов. Даже простые изменения могут ускорить пайплайн в 2–3 раза. А главное — вы перестаёте платить за простой.


🔥 Ресурсы:
- Официальная дока по кэшу https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows


#devops #девопс

Подпишись 👉@i_DevOps

⚡ 22 апреля вебинар Luntry: «Безопасность контейнеров и Kubernetes для специалистов анализа качества». 

Пройдем путь от приложения — «чёрного ящика» в контейнерном исполнении до полного понимания, что это за средство, как оно устроено и насколько все хорошо (или плохо) с безопасностью.

Запишитесь, чтобы получить напоминание и не пропустить эфир. Всем, кто зарегистрировался, вышлем полезные материалы после вебинара. 
Регистрация здесь

#реклама
О рекламодателе

Dokploy — Самый простой способ развернуть и управлять вашими контейнерами

Dokploy — это open-source инструмент для деплоя и управления контейнерами, разработанный для упрощения процессов CI/CD и DevOps. Он позволяет разработчикам легко развёртывать, управлять и масштабировать приложения без необходимости писать сложные скрипты или конфигурации.

Возможности:
- 🚀 Быстрый деплой контейнеров
- 🔄 Автоматическое обновление на основе webhook’ов
- 🧩 Простая интеграция с GitHub
- 🔒 Безопасное хранение переменных окружения
- 📦 Поддержка множества приложений
- 🛠️ Web UI и CLI для управления

Как это работает:
1. Подключаете свой репозиторий GitHub.
2. Dokploy следит за изменениями и автоматически деплоит ваше приложение.
3. Управляете всем через простой UI или CLI.

Цель проекта — дать каждому разработчику простой и эффективный способ доставки своего кода в прод.

https://github.com/dokploy/dokploy

#devops #девопс

Подпишись 👉@i_DevOps

Что такое userspace, kernelspace? Чем они отличаются?

Под пользовательским пространством понимается весь код операционной системы, который находится вне ядра.

Большинство Unix-подобных операционных систем (включая Linux) поставляются с разнообразными предустановленными утилитами, средствами разработки и графическими инструментами — это все приложения пространства пользователя.

Все пользовательские приложения (и контейнеризированные, и нет) при работе используют различные данные, но где эти данные хранятся?

Ядро обеспечивает абстракцию для безопасности, оборудования и внутренних структур данных. Например, системный вызов open() используется для получения дескриптора файла в Python, C, Ruby и других языках программирования. Вряд ли бы вы хотели, чтобы ваша программа работала с XFS на уровне битов, поэтому ядро предоставляет системные вызовы и работает с драйверами. Фактически этот системный вызов настолько распространен, что является частью библиотеки POSIX .

Краткое определение:

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

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

#devops #девопс

Подпишись 👉@i_DevOps

CI/CD пайплайны на стероидах: 5 фишек для ускорения сборок 🚀

⏱ Устали ждать, пока пройдут все джобы в CI? Время — деньги, особенно на продакшене. Вот 5 проверенных способов прокачать скорость и стабильность пайплайнов.


1. Кэширование зависимостей — must have
Кэшируйте node_modules, .m2, Docker-слои или Python virtualenv.
В GitHub Actions:

   - uses: actions/cache@v3
     with:
       path: ~/.npm
       key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
   

2. Matrix strategy для параллельных задач
Разбейте тесты по окружениям, версиям или компонентам:

   strategy:
     matrix:
       python: [3.9, 3.10]
   

3. Docker Layer Caching (DLC)
В GitLab CI включайте DLC:

   variables:
     DOCKER_DRIVER: overlay2
     DOCKER_TLS_CERTDIR: ""
   services:
     - docker:dind
   

4. Пропускайте джобы при отсутствии изменений
Нет изменений в директории — не триггери билд. В GitHub Actions:

   on:
     push:
       paths:
         - 'src/**'
         - '!docs/**'
   

5. Self-hosted runners для тяжёлых задач
Сильная машина с нужными зависимостями сэкономит десятки минут. Плюс — контроль среды и логирования.


Вывод:
Оптимизация CI/CD — это не про магию, а про дисциплину: кэш, параллелизм, условные шаги и правильные раннеры. Регулярно профилируйте пайплайны и фиксируйте bottlenecks.

#devops #девопс

Подпишись 👉@i_DevOps

#vacancy #DevOps #fulltime #вакансия #москва

DevOps

Локация: Москва
ЗП: 200к-350к net
Занятость: Полная, Гибридный формат
Оформление: ТК РФ
Компания: Федеральное Медико-биологическое агентство

ЦСП ФМБА занимается научными исследованиями связанными с геномом человека и анализом полученных данных.
Группа разработки создает внутренние сервисы для автоматизации движения, обработки и распределенного хранения больших объемов данных.

Требования:

•Опыт работы с Kubernetes обязателен
•Уверенные знания Linux, систем виртуализации и контейнеризации
•Опыт реализации CI/CD, большой опыт работы с Ansible и Git
•понимание работы web-серверов, балансировщиков и брокеров сообщений (на примере Nginx, Kafka)
•Понимание работы сетей и распределенных систем
•Опыт настройки и использования систем мониторинга: Zabbix, Grafana, Prometheus, ELK Stack
•Понимание процессов ITSM
•Законченное высшее образование


Чем предстоит заниматься:

•Настройка и последующая поддержка процессов CI/CD внутренних и публичных сервисов в различных окружениях
•Обеспечение непрерывной работоспособности и доступности сервисов
•Мониторинг систем, оптимизация производительности приложений и инфраструктуры, траблшутинг
•Настройка и управление Kubernetes
•Документирование процессов и систем
•Выстраивание процессов работы с командой разработки, командой данных, системными администраторами, Service Desk

Стек:
•Ubuntu, ALT Linux, Oracle
•Git, Gitlab-CI, Ansible, Terraform, Molecule
•Docker, Kubernetes
•Nginx, Haproxy, Traefik, Hashicorp Vault, MinioS3, Harbor, Consul, Postgres, Mariadb, Kafka
•Grafana, ELK, Prometheus, Loki, Victoria Metrics, Zabbix
•Bash, Python

Мы предлагаем:

•Оформление по ТК РФ.
•Работа в команде профессионалов на стыке передовых ИТ и науки. Мы работаем с Big Data и ML, у нас собственный корпоративный ЦОД.
•Только современное оборудование для рабочих мест.
•Прикрепление к корпоративной поликлинике.
•Возможность профессионального роста, обучение.
•График работы 5/2, гибрид, плавающее начало рабочего дня

Резюме отправлять: @ddsh_kl

Kubernetes: секреты быстрого rollback без боли и даунтайма

🔄 Rollback — неотъемлемая часть стабильного продакшена. Но сколько раз он превращался в хаос? Рассмотрим, как грамотно настроить откат в Kubernetes, чтобы не терять трафик, не ловить панику и не тратить часы на ручное восстановление.


🔹 1. Стратегия деплоя имеет значение

По умолчанию Deployment использует стратегию RollingUpdate. Это безопасно, но не всегда быстро. Убедись, что параметры maxUnavailable и maxSurge оптимальны:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

➡️ Это даст zero downtime, но при большом количестве реплик откат будет медленным. Подстрой под нагрузку.


🔹 2. Используй kubectl rollout undo

Kubernetes хранит предыдущие ReplicaSets, так что простой rollback — дело одной команды:

kubectl rollout undo deployment my-app

Проверь текущую ревизию:

kubectl rollout history deployment my-app

📝 Храни истории изменений в git — манифесты должны быть version-controlled.


🔹 3. Хелм под капотом? Настрой helm rollback

Если ты используешь Helm, rollback проще:

helm rollback my-release 1

❗️Важно: иногда rollback не возвращает ConfigMap или Secret, если они были изменены. Используй флаг --recreate-pods или закладывай изменения в values.yaml через hash-аннотации.


🔹 4. Прогревай rollback заранее

На preprod окружении сделай dry-run откатов. Проверь:

- есть ли живая предыдущая ревизия
- не изменились ли зависимости (например, база данных)
- как себя ведёт app после downgrade


🔹 5. Автоматизируй возврат

Сценарий: новая версия падает по хелсчекам. Вместо ручного вмешательства — automation:

- Настрой alertmanager на провал readiness/liveness
- Свяжи с Argo Rollouts или Spinnaker, чтобы триггерить rollback автоматически


✅ Вывод: грамотный rollback — это не кнопка “назад”, а часть CI/CD культуры.

Обеспечь:

- контроль версий манифестов
- мониторинг после деплоя
- rollback как часть стратегии, а не костыль


#devops #девопс

Подпишись 👉@i_DevOps

Кто вы в зоопарке DevOps-тулзов?

Каждый день вы приручаете зверей CI/CD, но вместо управляемой экосистемы — хаос?

Kubernetes может стать тем самым ядром, которое унифицирует ваши процессы. 👉На курсе «Kubernetes Мега» от Слёрма вы освоите K8s как основу для построения эффективной и управляемой CI/CD платформы.

Вы овладеете:
🔸 Переносом продукта на K8s без боли
🔸 Настройкой отказоустойчивых кластеров
🔸 Мгновенным траблшутинг и уверенное устранение инцидентов
🔸 Повышением стабильности и безопасности приложений
🔸 Автоматизацией: ротация сертификатов, автодеплой, безопасное хранение секретов

Старт уже 21 апреля
Осталось всего 7 мест

Программа и регистрация ➡️ по ссылке
Не дайте своим DevOps-зверям вырваться из-под контроля!

#реклама
О рекламодателе
erid: 2W5zFJGbtkx

HULL - Helm Uniform Layer Library

Этот репозиторий содержит библиотечную диаграмму Helm под названием HULL. Она предназначена для упрощения создания, поддержки и настройки объектов Kubernetes в Helm-диаграммах и может быть добавлена к любой Helm-диаграмме в качестве дополнения для расширения функциональности без риска нарушения существующих конфигураций Helm.

Сама диаграмма и вся связанная с ней документация находятся в папке hull, которая является корневой директорией библиотечной Helm-диаграммы HULL.

https://github.com/vidispine/hull

#devops #девопс

Подпишись 👉@i_DevOps

Kubernetes: правильный подход к ресурсным лимитам и requests

🔧 Часто недооценённая, но критичная тема для стабильности и производительности кластеров.


🎯 Зачем это важно?
Неверные значения requests и limits приводят либо к перерасходу ресурсов, либо к OOM, Throttling и подам, которые бесконечно перезапускаются. Особенно больно это бьёт по продакшену.


🚀 Как правильно настраивать ресурсы:

1. Понимай разницу между requests и limits:
- requests — это гарантированный минимум, который получит контейнер.
- limits — это максимум, выше которого контейнер не сможет использовать (CPU throttling или OOMKill для памяти).

2. CPU — без жестких лимитов:
- Лучше не указывать limits.cpu, чтобы избежать throttling.
- Но обязательно ставь requests.cpu, чтобы kube-scheduler мог правильно распланировать нагрузку.

3. Memory — всегда с лимитом:
- Память не отбирается — контейнер либо получает всю, либо OOM.
- Обязательно ставь и requests.memory, и limits.memory.

4. Используй VPA (Vertical Pod Autoscaler):
- Он поможет подобрать адекватные значения ресурсов на основе истории.
- ⚠️ На проде использовать осторожно — часто в "recommendation only" режиме.

5. Метрики в помощь:
- Используй kubectl top, metrics-server, Prometheus/Grafana для анализа потребления.
- Наблюдай за container_cpu_usage_seconds_total, container_memory_usage_bytes.

6. Профилируй и оптимизируй:
- Легковесный nginx или sidecar не должен просить 500Mi памяти.
- Java-приложение без указанных лимитов съест весь узел.


🧠 Вывод:
Грамотно выставленные ресурсы — это баланс между надёжностью и эффективным использованием нод. Не копируй requests/limits вслепую из интернета — мерь, анализируй, настраивай под свой ворклоад.


#devops #девопс

Подпишись 👉@i_DevOps

Cilicon - это приложение для macOS, использующее фреймворк виртуализации Apple для создания, предоставления и запуска эфемерных виртуальных машин CI с производительностью, близкой к нативной. В настоящее время оно поддерживает Github Actions, Buildkite Agent, GitLab Runner и произвольные скрипты.

В зависимости от ваших настроек, вы сможете запустить свой собственный CI в считанные минуты 🚀.


https://github.com/traderepublic/Cilicon

#devops #девопс

Подпишись 👉@i_DevOps

CI/CD как часы: 7 трюков для ускорения GitHub Actions 🚀

Иногда GitHub Actions начинает "плыть": воркфлоу, который вчера собирался за 5 минут, сегодня крутится 15+. Это не баг, а сигнал — пора оптимизировать пайплайн.

Вот подборка проверенных техник, чтобы ускорить и удешевить GitHub Actions без потери функциональности:


🔹 1. Используй actions/cache грамотно
Кэширование зависимостей (node_modules, .m2, vendor, pip) — простой способ ускорить билд на 30–70%.
Пример для npm:

- uses: actions/cache@v3
  with:
    path: ~/.npm
    key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
    restore-keys: ${{ runner.os }}-npm-

🔹 2. Разделяй и властвуй: job matrix
Параллельный запуск на разных версиях языка или ОС:

strategy:
  matrix:
    node: [16, 18]
runs-on: ubuntu-latest
steps:
  - uses: actions/setup-node@v3
    with:
      node-version: ${{ matrix.node }}

🔹 3. Минимизируй checkout и ненужные шаги
Не всегда нужно тянуть весь git-репозиторий. Добавь:

- uses: actions/checkout@v4
  with:
    fetch-depth: 1

🔹 4. Self-hosted runners — когда билд тяжелый
Они быстрее, могут иметь предустановленные зависимости, и ты не платишь за минуты. Особенно актуально для Java и .NET проектов.

🔹 5. Используй workflow_dispatch для ручных прогонов
Иногда удобно запускать воркфлоу вручную — например, для релизов или прогонов e2e.

on:
  workflow_dispatch:

🔹 6. Логируй аккуратно — логи тоже грузят
Слишком подробные логи замедляют UI и усложняют дебаг. Используй ::group:: и ::endgroup:: для логических блоков.

🔹 7. Закладывай timeouts
Иногда job висит из-за одного зависшего шага. Укажи timeout, особенно для e2e или deploy-джобов:

jobs:
  build:
    timeout-minutes: 15

Вывод:
GitHub Actions — мощный инструмент, но требует тонкой настройки. Оптимизация кэша, параллелизм, сокращение шагов и self-hosted runners могут сэкономить часы CI и сотни долларов на GitHub billing.

#devops #девопс

Подпишись 👉@i_DevOps

🧑🏻‍💻Хотите стать Python-разработчиком, но не знаете, с чего начать?

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

Обучение «Python Developer. Basic» — это интенсивная программа, которая проведет вас от новичка до первого проекта. Вы освоите основы Python, научитесь работать с фреймворками FastAPI и Django, освоите работу с базами данных и API. Получите все необходимые навыки для позиции уверенного junior-разработчика.

🐍Узнайте подробности, оставьте заявку и получите скидку на обучение: https://vk.cc/cKTACa

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Глубокое погружение в запросы, лимиты и специфику использования CPU в Kubernetes

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

https://habr.com/ru/companies/flant/articles/898190/

#devops #девопс

Подпишись 👉@i_DevOps

CI/CD под нагрузкой: оптимизация пайплайна для high-load проектов 🚀

Когда репозиторий растёт, а коммиты летят один за другим — CI/CD превращается из помощника в тормоз. Но всё можно оптимизировать.

Зачем это нужно:
Медленные пайплайны тормозят разработку, повышают стоимость инфраструктуры и раздражают команду. Ниже — конкретные приёмы, как ускорить и облегчить CI/CD для high-load проектов.


🔹 1. Параллельность — наше всё
Используй matrix стратегии (в GitHub Actions) или parallel блоки (в GitLab CI). Тестируй сразу на нескольких версиях среды или запускай независимые шаги одновременно. Пример:

strategy:
  matrix:
    python-version: [3.10, 3.11]

🔹 2. Кэшируй агрессивно
Настрой кэш зависимостей, Docker-слоёв, результатов компиляции. Это сильно снижает время на сборку. В GitHub Actions:

- uses: actions/cache@v3
  with:
    path: ~/.cache/pip
    key: ${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }}

🔹 3. Разделяй и властвуй
Разбей монолитный пайплайн на микропайплайны: unit-тесты, линтеры, деплой — по отдельности. Используй needs: только при настоящей зависимости. Это повышает параллельность и устойчивость.

🔹 4. Запускай не всё подряд
Добавь paths: или only/except фильтры. Зачем гонять e2e, если изменился только README?

on:
  push:
    paths:
      - 'src/**'

🔹 5. Используй артефакты — разумно
Вместо перекомпиляции перед каждым шагом, сохраняй и передавай промежуточные сборки. Это особенно полезно для Java/Go/Node проектов.


Вывод:
Оптимизация пайплайна — не только про скорость. Это про контроль над процессом и уменьшение издержек. Начни с малого — кэш, фильтры, параллельность — и постепенно адаптируй под свой проект.

#devops #девопс

Подпишись 👉@i_DevOps

📕Открытый урок о NoSQL с Cassandra для разработчиков, администраторов, специалистов по базам данных, Data engineers, Backend и FullStack-разработчиков.

На открытом уроке 21 апреля в 20:00 мск мы погрузимся в тонкости работы c NoSQL в Cassandra.

📗В результате вы:
- Узнаете, как работает Cassandra и какие есть особенности про которые никто говорит;
- Разберетесь, как избежать и решать проблемы в работе Сassandra;
- Освоите техники и лайфхаки в Сassandra на практике.

Спикер Дмитрий Гурьянов — Team Lead команды разработки CRM-решений на платформе .NET в Промсвязьбанке, 9+ лет в разработке, работал в Microsoft над продуктом Bing, аспирант кафедры "Системы обработки информации и управления" в МГТУ им. Н.Э. Баумана.

👉Регистрируйтесь прямо сейчас, чтобы не пропустить мероприятие: https://vk.cc/cKWWeo

📙Все участники открытого урока получат скидку на курс "Базы данных"

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576