Дякую за посилання, отримав нові знання. Ніколи не замислювався про існування такої проблеми. Як на мене, валідне використання pre-commit хуків на стороні сервера у цьому випадку.
Ваше посилання на статтю не працює, має бути якась публічна жінка.
Стосовно серверних хуків, не бачу нічого поганого у їх використанні. Ми налаштовували для gitlab і окрім згаданого вами варіанту про зламані MR ми ще додавали перевірку на наявність Jira ticket у описі. На відміну від client side їх не можливо проігнорити.
Тут було б цікаво почути його аргументацію, але давайте поміркуємо.
Єдине що приходить на думку — це так звана supply chain attack, тобто якщо ми використовуємо зовнішній репозиторій в якому описані дії які ми робимо з нашим кодом то у разі компроментації — може трапитись щось погане. Цьому дійсно треба приділяти увагу, а саме:
1. Використовуємо відомі і підтримувані репозиторії.
2. Використовуємо теги а не main ref
3. Найбільш критичне що може статися — це витік даних назовні, в мене стоїть Little Snitch на Mac який блокує по дефолту будь яку нову комунікацію назовні.
Якщо є ще якісь потенційні проблеми — пишіть, обсудимо.
Тут ніколи не вгадаєш. Я теж дуже полюбляю «унікальний» контент, який ще ніхто і ніде не писав але чим більше читаєш тим менше бачиш таких можливостей. Можливо не треба писати статтю і потім відкладати публікацію на місяць лише по причині, що вже було дві статті минулого місяця :)
Зазвичай менше
Ні, скарг не було, тим паче, що це налаштовується на стороні розробника — якщо йому ну прям зовсім не заходе — він може вимкнути персонально у себе.
У нашій команді DevOps інженерів на сьогодні немає дівчат і мені було цікаво познайомитися саме із леді- інженерами.
Не дочитавши до кінця хотів написати, що при цьому в нас був дуже позитивний досвід з дівчиною DevOps. Але вже далі по тексту побачив що це згадується.
Сподіваюсь що ми виправимо ситуацію у найближчому часі і в нас буде навіть не одна дівчина інженер.
Знову перевірили — той самий ефект, картку прийняло але на етапі “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”. Тобто все так як було, релоад не допомогає, сапорт допомогти не може )
Нарешті дійшли руки глянути що там фейлиться:
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.
Наскільки важко перейти на свіжишу версію я не знаю
Цікавий досвід. Мені на думку спадають лише якісь DVR, які можуть не мати підтримки ARM або проблеми, з рештою не стикався. Велика комʼюніті навколо малинки популяризувала ARM і маємо багато проектів на любий смак адаптованих під неї. У Jeff Geering є багато прикладів з різними платами і девайсами, я лише дивився але сам не грався.
Так, саме польску прийняло але далі застопорилося. Скажу колезі щоб ще раз спробував.
Не впевнений що там було в середині, але начебто аналог 8086. Мій перший компʼютер «Электроника МС 1502» )
Сам не пробував але чув від колег (десь три тижні тому), що воно начебто і можна, але то картка йому не подобається або сприймає картку але не створює аккаунт. Ну а саппорт OracleCloud не дуже спішить допомагати з таким кейсом.
Дякую, цікаво. Треба буде якось заміряти.
«Змішались в купу коні, люди...»
Ну так тут очевидно :) Для мене це дійсно лише гарні назви, які зустрічалися у новинах або в розсилках. Інколи навіть читав про проблеми з якими стикаються інженери при роботі з ними, як ті що наведені у вас.
Чи пробує оптимізувати тонкі місця асемблером (хоча це зараз майже ніколи не корисно).
Можете назвати імена?
Один з проектів це скрапінг даних, гляну які там залежності та відпишусь.
> Використання гравітонів для бази та 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» :)
В моїй голові воно звучало краще ніж коли опинилося у тексті :)
Цікаво, не вимірював і не помічав якоїсь різниці. Ваш досвід стосується якої саме, Aurora for MySQL чи Aurora for PostgreSQL?
Привіт. Просто цікаво, у вас гітхаб? Наче лише вони надають доступ до різних архітектур, у решти на селф хостед ранерах можливо нібито це робити.
Те що ви процитували — саме те місце. Control plane/master nodes знаходяться десь у AWS але в cluster subnets створюються ENI для комунікації з ними. Я викривив інформацію чи щось інше?
Так, згоден, але це коли проект вже великий та має якісь свої «історично склалося». Якщо це стартап чи міграція з on-premise то більший вплив мають вподобання інженера (команди). Отже кожен обирає те, що знає і добре якщо знає декілька і може обізнано обрати найкращий варіант. Це, доречі, стосується вибору будь якого інструменту, і нічого поганого нема в тому, що обирають те що знають, але погано, якщо це не ідеальний вибір.
Дуже змістовний комент, дякую. Я так розумію, що перелічили усе що знали і на вашу думку кожен з цих інструментів мав бути згаданий у статті? Щось мені підказує, що це не влізе і в 10 статей, хоча якщо напишите — залюбки почитаю та прокоментую.
З OpenSearch вектор працює без проблем, ліміт на кількість шардів — так, є така штука, наступали на ці граблі. Про довгі строки була проблема, але начебто не на стороні вектору а на стороні php-fpm, все вирішили.
Стосовно втрати логів — це як раз та ситуація яку вирішили складанням у S3 перед відправкою в OpenSearch.
Дякую за відгук