Помню играл в нее в обратную сторону. Дошел почти до финального выстрела и повернулся против своих. Обратно играть оказалось сложнее и изобретательнее.
Нападает на крепость толпа зомбаков. - крепостные ворота их пропустили - по улицам пройти их пропустили - в дом зайти им позволили и вот тут уже в прихожей мы херачим их скалкой.
Может таки низкоуровневые атаки делегировать более низкому уровню?
В первом комментарии, равно как и в калькуляторе на сайте есть важная приписка за 1 vCPU !!! то есть 1 проц = 68 руб за штуку (68 руб итого) 2 проца = 120 руб за штуку (240 руб итого) 3 проца = 204 руб за штуку (612 руб итого)
повторюсь за штуку, а не за весь сет!
в этом и есть суть моего возмущения в первом комментарии.
Я с вами соглашусь, но я имел ввиду немного другое.
Минимальная стоимость 68 рублей за 1 vCPU, и, привычно, предполагаешь что увеличение количества vCPU просто кратно увеличит стоимость. Например, я предполагал, что за сервер с 2 vCPU я бы отдавал 126 рублей. Но нет же. 2 vCPU будет уже 240 рублей. А 4 vCPU уже 816.
В разрезе динамического масштабирования вас ожидает весьма неприятный расчет.
Открыл для себя подкасты как полезную замену музыке по пути на работу и с работы, при условии что ты не за рулем. Отлично раздвигает границы кругозора, ну и ощущаешь себя причастным к тусовке ))) Между скобок, подлодка, пятиминутка php — респект ребятам!
Да там не чувствуешь ничегошеньки, сидишь, а доктора тебе нос через рот чистят :-)
Потом дрелят там что-то, короче чувствуешь себя скорее автомобилем на ТО.
Единственный минус потом лицо дня на три разносит люто.
Вот так все и было! 40 лет назад фиговыми технологиями начали двигать зубы, плюс плохая гигиена и курение. И все. Под зубами все плохи с зубами тоже. Поэтому все зубы на выход, ставим конструкции, бросаем курить и все становится гораздо лучше.
Через полгода ощущается как своя. Отличие в мягкости, так как естественные зубы сидят в кости через мягкую прокладку, и при кусании она как бы демпфирует, а при кусании этой хреновиной демпфирования нет, так как конструкция жесткая. Непривычно первое время делается клац-клац зубами. Но потом привыкаешь.
Как обладатель полного рта имплантов скажу: «Ирригатор просто незаменимая вещь!». Даже если вы счастливые зубастики, вам тоже очень очень рекомендую это устройство.
Ведь все оказывается очень просто — нет постороннего на деснах и под ними, и десны растут как надо и куда надо. Как только там что-то залеживается, они стремятся убежать от этого места. Вот и вся логика.
Правда проверенная на себе и стоимостью в 1 млн.
Да, конечно, в большой компании могут быть сервисы с разными версиями баз и т.п. При этом, сугубо на мой взгляд, докер только увеличит энтропии в системе. Один сервис на том, другой на этом, пятый вообще через опу запускается. Да, можно с легкостью описать это все в конфигах и работать с тем что досталось, но мне кажется неправильным. Получается инструмент для управления хаосом, хоть и весьма удобный, а задача уменьшить этот хаос отодвигается все дальше и дальше.
Но все это мои, ретроградные рассуждения, возможно я просто не умею все это готовить )))
Вот тут докер как раз будет уместен, я так считаю. Хотя если все сайты ваши, а не клиентские, то выровнять версии ПО на серверах и у себя проблем не составит.
disclaimer: Я ретроград
Мне кажется с докером и кубером сейчас происходит то же что и с {any_js_framework}, а именно докер+кубер пихают везде куда ни попадя.
Развертывание приложений — если вы производите сотни развертываний приложения в день может быть тут и будет полезен этот стек. Но черт побери — зачем столько развертываний? Ну хорошо, даже если нужно столько развертываний, то просто привези код на сервер и запусти. Для этого подойдут обычные CI/CD методики. При этом программисты будут делать свою работу, а админы свою.
Масштабирование: если вы разрабатываете приложение с возможным взрывным ростом, то наверняка делаете это сразу в облаках и, теоретически, неограниченными техническими возможностями. В таком случае кубер хорошее решение. В остальных случаях, имхо, проще добавить серверов классическим методом, и немного изменить скрипты CI/CD для доставки приложения на большее число серверов.
Локальная разработка — да, проще поднять свою копию приложения в докер контейнерах и разрабатывать локально используя их, но это касается весьма больших приложений с увесистым стеком технологий. В остальном же поднять вебсайтик локально можно и без докеров и куберов.
Доходит до истерических примеров. Приложения написанные на golang, и представляющие собой один бинарник упаковывают в докер.
Потом смотришь — лендинг, а под ним OS — VM — k8s — docker — PM2 — Reakt(в котором jQuery и куча тяжелых библиотек) и все это лютейшим образом тормозит, жрет половину мощности хорошего сервака, и падает через каждые 20 минут от пережора памяти, весело прибиваемое OOM и так же весело рестартуя.
Мне кажется инструменты следует применять с умом и по необходимости.
Помню играл в нее в обратную сторону. Дошел почти до финального выстрела и повернулся против своих. Обратно играть оказалось сложнее и изобретательнее.
Вот это годнота! Спасибо! Теперь я знаю куда девать гироскутер, с которого я упал и сломал руку. Решено, делаю самокат!
Нападает на крепость толпа зомбаков.
- крепостные ворота их пропустили
- по улицам пройти их пропустили
- в дом зайти им позволили
и вот тут уже в прихожей мы херачим их скалкой.
Может таки низкоуровневые атаки делегировать более низкому уровню?
Чтобы зарегистрировать красивый ИНН 😂
В первом комментарии, равно как и в калькуляторе на сайте есть важная приписка
за 1 vCPU !!!
то есть
1 проц = 68 руб за штуку (68 руб итого)
2 проца = 120 руб за штуку (240 руб итого)
3 проца = 204 руб за штуку (612 руб итого)
повторюсь за штуку, а не за весь сет!
в этом и есть суть моего возмущения в первом комментарии.
Я с вами соглашусь, но я имел ввиду немного другое.
Минимальная стоимость 68 рублей за 1 vCPU, и, привычно, предполагаешь что увеличение количества vCPU просто кратно увеличит стоимость. Например, я предполагал, что за сервер с 2 vCPU я бы отдавал 126 рублей. Но нет же. 2 vCPU будет уже 240 рублей. А 4 vCPU уже 816.
В разрезе динамического масштабирования вас ожидает весьма неприятный расчет.
Это конечно интересно, но смотря на ваш же продукт clo.ru возникают когнитивные искажения, и пользоваться им совершенно не хочется.
Вот взгляните
Цена за 1 vCPU зависит от общего количества ядер:
1 vCPU — 68 ₽ в месяц / 0,0914 ₽ в час за 1 vCPU
2 vCPU — 120 ₽ в месяц / 0,1613 ₽ в час за 1 vCPU
3-8 vCPU — 204 ₽ в месяц / 0,2742 ₽ в час за 1 vCPU
Казалось бы, оптом дешевле? Как бы не так. Одно ядро 68 руб за штуку, а два уже 120 за штуку! В чужом глазу, как говорится....
Открыл для себя подкасты как полезную замену музыке по пути на работу и с работы, при условии что ты не за рулем. Отлично раздвигает границы кругозора, ну и ощущаешь себя причастным к тусовке ))) Между скобок, подлодка, пятиминутка php — респект ребятам!
Обалдеть сколько вкусного завезли!
Отдельное спасибо за форматирование в max view!
Дык я про то и говорю, что и под местной анестезией не больно, а вот опухнешь потом в любом случае, нитки ещё эти )))
Потом дрелят там что-то, короче чувствуешь себя скорее автомобилем на ТО.
Единственный минус потом лицо дня на три разносит люто.
Ведь все оказывается очень просто — нет постороннего на деснах и под ними, и десны растут как надо и куда надо. Как только там что-то залеживается, они стремятся убежать от этого места. Вот и вся логика.
Правда проверенная на себе и стоимостью в 1 млн.
Но все это мои, ретроградные рассуждения, возможно я просто не умею все это готовить )))
Мне кажется с докером и кубером сейчас происходит то же что и с {any_js_framework}, а именно докер+кубер пихают везде куда ни попадя.
Развертывание приложений — если вы производите сотни развертываний приложения в день может быть тут и будет полезен этот стек. Но черт побери — зачем столько развертываний? Ну хорошо, даже если нужно столько развертываний, то просто привези код на сервер и запусти. Для этого подойдут обычные CI/CD методики. При этом программисты будут делать свою работу, а админы свою.
Масштабирование: если вы разрабатываете приложение с возможным взрывным ростом, то наверняка делаете это сразу в облаках и, теоретически, неограниченными техническими возможностями. В таком случае кубер хорошее решение. В остальных случаях, имхо, проще добавить серверов классическим методом, и немного изменить скрипты CI/CD для доставки приложения на большее число серверов.
Локальная разработка — да, проще поднять свою копию приложения в докер контейнерах и разрабатывать локально используя их, но это касается весьма больших приложений с увесистым стеком технологий. В остальном же поднять вебсайтик локально можно и без докеров и куберов.
Доходит до истерических примеров. Приложения написанные на golang, и представляющие собой один бинарник упаковывают в докер.
Потом смотришь — лендинг, а под ним OS — VM — k8s — docker — PM2 — Reakt(в котором jQuery и куча тяжелых библиотек) и все это лютейшим образом тормозит, жрет половину мощности хорошего сервака, и падает через каждые 20 минут от пережора памяти, весело прибиваемое OOM и так же весело рестартуя.
Мне кажется инструменты следует применять с умом и по необходимости.
Собаку можно выгуливать ))