CTO в OpsWorks Co
  • Vector як альтернатива Logstash та Fluentd

    З OpenSearch вектор працює без проблем, ліміт на кількість шардів — так, є така штука, наступали на ці граблі. Про довгі строки була проблема, але начебто не на стороні вектору а на стороні php-fpm, все вирішили.
    Стосовно втрати логів — це як раз та ситуація яку вирішили складанням у S3 перед відправкою в OpenSearch.
    Дякую за відгук

    Підтримав: Dmytro Trofimchuk
  • Git pre-commit hooks для DevOps

    Дякую за посилання, отримав нові знання. Ніколи не замислювався про існування такої проблеми. Як на мене, валідне використання pre-commit хуків на стороні сервера у цьому випадку.

  • Git pre-commit hooks для DevOps

    Ваше посилання на статтю не працює, має бути якась публічна жінка.

    Стосовно серверних хуків, не бачу нічого поганого у їх використанні. Ми налаштовували для gitlab і окрім згаданого вами варіанту про зламані MR ми ще додавали перевірку на наявність Jira ticket у описі. На відміну від client side їх не можливо проігнорити.

  • Git pre-commit hooks для DevOps

    Тут було б цікаво почути його аргументацію, але давайте поміркуємо.
    Єдине що приходить на думку — це так звана supply chain attack, тобто якщо ми використовуємо зовнішній репозиторій в якому описані дії які ми робимо з нашим кодом то у разі компроментації — може трапитись щось погане. Цьому дійсно треба приділяти увагу, а саме:
    1. Використовуємо відомі і підтримувані репозиторії.
    2. Використовуємо теги а не main ref
    3. Найбільш критичне що може статися — це витік даних назовні, в мене стоїть Little Snitch на Mac який блокує по дефолту будь яку нову комунікацію назовні.

    Якщо є ще якісь потенційні проблеми — пишіть, обсудимо.

  • Git pre-commit hooks для DevOps

    Тут ніколи не вгадаєш. Я теж дуже полюбляю «унікальний» контент, який ще ніхто і ніде не писав але чим більше читаєш тим менше бачиш таких можливостей. Можливо не треба писати статтю і потім відкладати публікацію на місяць лише по причині, що вже було дві статті минулого місяця :)

  • Git pre-commit hooks для DevOps

    Зазвичай менше 2-3 секунд, інколи до 5-7. Справа в тому, що вони виконуються до того коду, в якому були зміни і дуже швидкі по своїй суті — літери і форматери коду не потребують запуску вашого проекту і виконання тестів. Вони в жодному разі не мають заміняти перевірки, які ми робимо на етапі CI, які більш комплексні і перевіряють вже весь код.
    Ні, скарг не було, тим паче, що це налаштовується на стороні розробника — якщо йому ну прям зовсім не заходе — він може вимкнути персонально у себе.

    Підтримали: Mykola Gatilov, Oleksandr Babenko
  • Чи є місце для Барбі у DevOps?

    У нашій команді DevOps інженерів на сьогодні немає дівчат і мені було цікаво познайомитися саме із леді- інженерами.

    Не дочитавши до кінця хотів написати, що при цьому в нас був дуже позитивний досвід з дівчиною DevOps. Але вже далі по тексту побачив що це згадується.
    Сподіваюсь що ми виправимо ситуацію у найближчому часі і в нас буде навіть не одна дівчина інженер.

    Підтримали: Natalya Kovalivska, Ganna Slavutska
  • Чи є життя на ARM-і — досвід міграції

    Знову перевірили — той самий ефект, картку прийняло але на етапі “Start my free trial” ловимо помилку “The number of requests has been exceeded. Reload the page or retry the operation. If the problem persists, then contact Oracle Support”. Тобто все так як було, релоад не допомогає, сапорт допомогти не може )

  • Чи є життя на ARM-і — досвід міграції

    Нарешті дійшли руки глянути що там фейлиться:

    67.84 make -e -C modules/common libaerospike-common.a 67.84 make[1]: Entering directory '/temp_build/aerospike-client-c/modules/common' 67.91 cc -Isrc/include -std=gnu99 -g -Wall -fPIC -O3 -fno-common -fno-strict-aliasing -D_FILE_OFFSET_BITS=64 -D_REENTRANT -D_GNU_SOURCE -march=nocona -finline-functions -rdynamic -o target/Linux-aarch64/obj/common/aerospike/as_aerospike.o -c src/main/aerospike/as_aerospike.c 67.92 cc1: error: unknown value 'nocona' for -march 67.92 cc1: note: valid arguments are: armv8-a armv8.1-a armv8.2-a armv8.3-a armv8.4-a native

    Причина — ARM support wasn’t added until Aerospike Client Library version 8.0.0.
    Наскільки важко перейти на свіжишу версію я не знаю

  • Чи є життя на ARM-і — досвід міграції

    Цікавий досвід. Мені на думку спадають лише якісь DVR, які можуть не мати підтримки ARM або проблеми, з рештою не стикався. Велика комʼюніті навколо малинки популяризувала ARM і маємо багато проектів на любий смак адаптованих під неї. У Jeff Geering є багато прикладів з різними платами і девайсами, я лише дивився але сам не грався.

  • Чи є життя на ARM-і — досвід міграції

    Так, саме польску прийняло але далі застопорилося. Скажу колезі щоб ще раз спробував.

  • Чи є життя на ARM-і — досвід міграції

    Не впевнений що там було в середині, але начебто аналог 8086. Мій перший компʼютер «Электроника МС 1502» )

  • Чи є життя на ARM-і — досвід міграції

    Сам не пробував але чув від колег (десь три тижні тому), що воно начебто і можна, але то картка йому не подобається або сприймає картку але не створює аккаунт. Ну а саппорт OracleCloud не дуже спішить допомагати з таким кейсом.

    Підтримав: Pavlo Vasylchenko
  • Чи є життя на ARM-і — досвід міграції

    Дякую, цікаво. Треба буде якось заміряти.

  • Чи є життя на ARM-і — досвід міграції

    «Змішались в купу коні, люди...»

    Ну так тут очевидно :) Для мене це дійсно лише гарні назви, які зустрічалися у новинах або в розсилках. Інколи навіть читав про проблеми з якими стикаються інженери при роботі з ними, як ті що наведені у вас.

    Чи пробує оптимізувати тонкі місця асемблером (хоча це зараз майже ніколи не корисно).
    Можете назвати імена?

    Один з проектів це скрапінг даних, гляну які там залежності та відпишусь.

    > Використання гравітонів для бази та Redis дає в нашому випадку суттєвішу економію.
    Ось це цікаво. Є уявлення, за рахунок чого таке стається?

    Можливо я не зовсім коректно пояснив. Мова йде про RDS Aurora for MySQL and ElasticCache for Redis. В нашому випадку бази достатньо великі і ми маємо Writer/Reader setup. Якщо порівняти вартість db.r5.2xlarge = $934.4 і db.r6g.2xlarge = $845.34 то це $89.06 на writer і стільки ж на reader. Без докладання жодних зусиль, просто обравши інший тип інстансу.

    Якщо порівняти вартість спот інстансів — то t3a.xlarge ~= $100 і t4g.xlarge ~= 95$ (залежить від AZ) ми маємо економію у 5$ при середній кількості інстансів ~10. При цьому нам потрібно докладати зусиль щоб все це налаштувати.

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

    PS: По назві статті подумав про якийсь «ARM-i» :)

    В моїй голові воно звучало краще ніж коли опинилося у тексті :)

    Підтримав: Natalya Kovalivska
  • Чи є життя на ARM-і — досвід міграції

    Цікаво, не вимірював і не помічав якоїсь різниці. Ваш досвід стосується якої саме, Aurora for MySQL чи Aurora for PostgreSQL?

    Підтримав: Natalya Kovalivska
  • Чи є життя на ARM-і — досвід міграції

    Привіт. Просто цікаво, у вас гітхаб? Наче лише вони надають доступ до різних архітектур, у решти на селф хостед ранерах можливо нібито це робити.

    Підтримав: Natalya Kovalivska
  • Свідомо розгортаємо кластер AWS EKS

    Те що ви процитували — саме те місце. Control plane/master nodes знаходяться десь у AWS але в cluster subnets створюються ENI для комунікації з ними. Я викривив інформацію чи щось інше?

    Підтримав: Oleksandr Savchenko
  • Свідомо розгортаємо кластер AWS EKS

    Так, згоден, але це коли проект вже великий та має якісь свої «історично склалося». Якщо це стартап чи міграція з on-premise то більший вплив мають вподобання інженера (команди). Отже кожен обирає те, що знає і добре якщо знає декілька і може обізнано обрати найкращий варіант. Це, доречі, стосується вибору будь якого інструменту, і нічого поганого нема в тому, що обирають те що знають, але погано, якщо це не ідеальний вибір.

  • Свідомо розгортаємо кластер AWS EKS

    Дуже змістовний комент, дякую. Я так розумію, що перелічили усе що знали і на вашу думку кожен з цих інструментів мав бути згаданий у статті? Щось мені підказує, що це не влізе і в 10 статей, хоча якщо напишите — залюбки почитаю та прокоментую.

← Сtrl 12 Ctrl →