DevOps.Ищу опыт
Доброго дня,господа и дамы.
Я линуксовый админ и решил постигать азы девопесинга.
Если кому надо помощь с вашими проектами - готов на безвозмездной основе.
Могу по линуксу чего,ansible,docker,разверну кубер,настрою nginx\apache,пытаюсь в ci\cd.
контакты для связи nakedpeak272@gmail.com
Линь это здорово, но...
Импортозамещение,становится ближе к пользователю, хуе-моё. Давеча импортозамещаю, для прокачки скиллов, чтобы с 1С работало.На Hyper-V, на неиспользуемой станции, у клиента, чего бы не развернуть, не ощутить, так сказать, тут же заодно 1С, можно проверить.
Проблемы начали вылезать откуда и не ждал. Используем Mesh для удаленного доступа, местами RMS от тектонита. В качестве теста ставил на виртуалку mint и предлагаемый MS в HV Ubuntu. Проблемы начались после установки сразу. Оказывается, корректно передавать в виртуалку через удаленное подключение ни та, ни другая система удаленного доступа не может. В Mesh вообще нормально ничего не написать, даже в терминале в гостевой, а в RMS только частично, знаки типа вопроса, запятой, тильда, вызывают непонятную реакцию типа вызова скриншота. В общем, работать невозможно, перенабирать длинные команды вручную такое себе. Да почему это вообще может не работать, обычное нажатие кнопок же, етить-мадрить! В виндовых гостевых все норм, что характерно.
Ладно, зависимости для 1с поставил, шрифты тоже. Ставим 1с... А можно как то проще запускать инсталлер, а не через перетаскивание инсталлера в терминал, где до того было набрано sudo su? например ПКМ и там в менюшке запуск от root? Это концепт такой, чтобы пользователь испытал максимальные трудности? Я предполагаю, что наверняка есть какие то проги, которые могут в контекстное меню эту фичу добавить. Но это же жопа для обычного пользователя, вздумавшего поставить что-то, отличное от содержимого стандартных репов. В дополнение к установке того же Mesh- там некислая такая строчка для выполнения на баше, которая, как мы помним, просто так не копируется в виртуалку. Бля, я всего лишь хочу запустить 1с на лине, что тут такого? Но на этом приключения не кончаются, мои дорогие читатели! Вздумал я невиданный разгул учинить- меня виртуалка предупреждала, что места мало (13г всего при штатной инсталяции бубунты от МС), а я проигнорировал, проказник. И получил в результате несоответствие количества суперблоков и размера дисков, которое ни gparted,ни fsck, устранить не смогли, в результате чего я получил рабочую только в "сейфмоде" виртуалку. Это эпик фейл, на мой взгляд, ибо та же самая винда при 13Мб свободного на диске, позволит загрузиться и вычистить хоть что-то для ее запуска.
К чему я этот пост то собственно. Да, есть вещи, которые есть только под линь и они там хорошо работают при условии выполнения требований к ним. Но бля, какого геморроя можно в лине огрести, если чуть вправо-влево от браузер-мессинджер-офис, то ну его нахуй (это я про рабочие места),лучше винды все же нет.
10 сравнительно новых DevOps инструментов, на которые стоит обратить внимание
В этой статье хотелось бы рассмотреть некоторые новые (относительно) инструменты DevOps, которые возможно кого-то заинтересуют, и при использовании помогут поднять производительность инженеров на новый уровень.
Pulumi
Давайте начнём с основы DevOps: инфраструктуры.
В первую очередь, Pulumi инструмент Infratructure as Code (IaC), в духе
Terraform, AWS CDK, CDK для Terraform итд.
Сегодня, хоть Terraform возможно и стал наиболее популярным выбором для IaC, у него есть ряд недостатков. Ну например:
Вы обязаны выучить новый "язык". В данном случае HCL.
HCL не достаточно функциональный (и я сейчас не про парадигму) язык, чтобы в нём было комфортно работать. Еще пару тройку лет назад в нём банально не было циклов for.
Но вернёмся к Pulumi.
Что он из себя представляет?
Если вы более-менее знакомы с AWS CDK, вам будет просто понять как он работает. Отличие может быть только в том, что он (Pulumi) пытается быть совместимым с каждым облаком.
Если вы еще не знакомы с AWS CDK, задумайтесь о знакомтсве: Pulumi позволяет вам управлять вашей инфраструктурой с любым (разумеется немаргинальным) языком программирования, который вы уже знаете. Это само собой исключает изучение еще одного ненужного в вашей жизни языка (если для вас конечно не ключевой задачей является строчка в резюме: HCL разработчик).
Короче говоря, если вы уже знакомы с какими-то языками программирования, например TypeScript, Python, Go, C#, Java, итд, и категорически не принимаете идею учить еще один новый язык - Pulumi для вас. Если вы используете AWS, технически вы можете использовать AWS CDK тоже, но если вы планируете заниматься оркестрацией гибридной облачной инфраструктуры, Pulumi сильно упростит вам жизнь.
Если вы уже используете Terraform в проде, но вас напрягают ограничения, накладываемые HCL, вы так же можете попытаться использовать Pulumi.
Этот инструмент давно не новый. Ему уже исполнилось почти 16к звездочек на github'e. Хотя по отношению к Terraform - он новый. Впрочем какая разница? Если он гипотетически может помочь решить ваши проблемы, то почему бы и не попробовать его?
SOPS
SOPS - сокращение от Secrets OPerationS. Это опенсорсный текстовый редактор файлов, который автоматически шифрует/дешифрует файлы.
Основные задачи на которых сосредоточено это приложение - редактирование, шифрование, и автоматизация.
Обычно, когда вы хотите зашифровать текстовый файл, вы делаете следущее:
Открываете любимый текстовый редактор, вносите правки в текст, и сохраняете файл.
Используете инструмент для шифрования/дешифрования для того, чтобы зашифровать весь файл.
Когда вам нужно прочитать зашифрованный файл:
Сначала берете специальный инструмент, и расшифровываете файл.
Открываете расшифрованный файл любимым текстовым редактором.
Недостаток этого процесса очевиден. Вам нужно два инструмента. С одной стороны текстовый редактор, с другой программа для шифрования информации. При этом задача остаётся на самом деле только одна.
И вот SOPS как раз и позволяет объединить два действия в одно.
Если очень кратко, он может быть интегрирован с такими сервисами как HashiCorp Vault, AWS KMS, etc) для расшифровки ваших зашифрованных файлов автоматически, а так же позволяет использовать git репозиторий для хранения ключей, что сильно упрощает рабочую коммуникацию.
Если вдруг заинтересовал инструмент, то в этой статье можно детально с ним ознакомиться.
Trivy
Контейнеризация и 12-факторные приложения (приложение как услуга) стали к настоящему времени настолько популярны, что когда у вас возникает задача что-то собирать и деплоить, вы не думаете ни о чём другом. С тех пор как мы стали зависимы от контейнеров в нашей инфраструктуре, стало важным поддерживать в актуальном состоянии безопасность хранимых образов, поскольку запускаемые из них контейнеры наследуют все характеристики родительских образов, в том числе уязвимости и неправильную конфигурацию.
Trivy - сканер безопасности. Он надёжен, быстро, и легок в использовании. У Trivy есть различные встроенные сканеры, которые призваны искать различные проблемы безопасности. Самый популярный вариант использования - поиск CVE. Второй по популярности - ошибки конфигурации.
Вы можете запускать Trivy как локально, с помощью CLI для сканирования локальных образов перед тем как отправлять их в реестр, или перед тем как деплоить ваше приложение.
Более того. Trivy разработан с возможностью без особого труда интегрироваться в CI пайплайны, что отлично согласуется с методологией DevOps.
Cluster API
Cluster API - это подпроект Kubernetes, ориентированный на предоставление декларативных API и оснастки упрощающей подготовку, обновление и эксплуатацию множества кластеров Kubernetes.
Запущенный Kubernetes Special Interest Group (SIG) Cluster Lifecycle, проект Cluster API использует API и шаблоны в стиле Kubernetes для автоматизации управления жизненным циклом кластера для операторов платформы. Вспомогательная инфраструктура, такая как виртуальные машины, сети, балансировщики нагрузки и VPC, а также конфигурация кластера Kubernetes определяются так же, как разработчики приложений развертывают свои рабочие нагрузки и управляют ими. Это обеспечивает согласованное и воспроизводимое развертывание кластера в самых разных инфраструктурных средах.
Если вас смущает официальное определение, подумайте так: вы можете запустить одну команду kubectl apply для создания кластера K8s, и она работает для AWS, Azure, DigitalOcean, Docker, GCP, OpenStack и других.
Не нужно создавать модули Terraform (или, что еще хуже, пытаться выяснить все параметры чужих модулей) для кластеров K8s, не нужно разбираться, как использовать eksctl для AWS и еще что-то для другого облака; просто применить kubectl для создания кластеров. Звучит впечатляюще, правда? Я знаю. Вот почему он и входит в этот список.
Linkerd
Linkerd - самая легкая и быстрая в мире service mash (по крайней мере, так говорят). Что такое service mash? Service mash — это выделенный уровень инфраструктуры для обеспечения безопасной, быстрой и надежной связи между сервисами.
Простота использования - вот ключевая фишка Linkerd. Вы можете установить его буквально одной командой.
Но давайте поговорим больше.
Настройка быстрая. Даже образы докеров маленькие, поэтому они загружаются быстрее.
Архитектура не сильно отличается. Существует плоскость управления и плоскость данных, где плоскость управления представляет собой набор служб, отвечающих за телеметрию, API, предоставление управляющих данных прокси плоскости данных и т. д., а плоскость данных имеет прокси, которые работают рядом с каждой службой. пример. Ознакомьтесь с официальным документом, если вы хотите узнать больше деталей.
Istio и AWS App Mesh используют прокси-сервер envoy с открытым исходным кодом — высокопроизводительный распределенный прокси-сервер C++, предназначенный для отдельных сервисов и приложений. Это сложный прокси общего назначения. Linkerd, с другой стороны, использует специально разработанный прокси-сервер, написанный на Rust, чтобы он был как можно меньше, легче и безопаснее. Я здесь не для того, чтобы судить, какой язык лучше и безопаснее, C++ или Rust, но как современный язык с особым способом управления памятью (собственность вместо сборки мусора) Rust определенно имеет преимущество.
Для управления несколькими кластерами, в отличие от Istio, Linkerd использует механизм зеркалирования сервисов. Настройка также относительно проста, почти как установка с одним кластером, за исключением того, что вам нужно сделать это дважды плюс плоскость управления с несколькими кластерами.
Подводя итог, Linkerd — это service mash другого типа: сверхлегкая, сверхпростая и сверхмощная. Linkerd добавляет безопасность, наблюдаемость и надежность в Kubernetes без каких-либо сложностей. Это не совсем новый инструмент, но если функции соответствуют вашим потребностям и вам нравится простота, попробуйте.
Github Actions
GitHub Actions — еще один CI.
Почему же тогда именно GitHub Actions?
Ну, во-первых, он находится в техническом радаре CNCF (и находится на стадии «оценки», превращая его в «новый» инструмент), поэтому нам как бы нужно хорошенько его рассмотреть.
Во-вторых, CI много взаимодействует с вашим кодом, и по своей природе GitHub Actions легко взаимодействует с вашими репозиториями GitHub. Больше никаких проблем с интеграцией CI с вашими репозиториями кода.
Еще одно преимущество для стартапов: у GitHub Actions есть некоторая бесплатная квота, поэтому, когда вы только что запустили новый продукт, бесплатной квоты может быть более чем достаточно, что делает его полностью бесплатным. Вам, вероятно, не нужно регистрировать несколько дополнительных самостоятельных исполнителей в течение довольно долгого времени, и вы экономите затраты на запуск некоторых виртуальных машин в каком-либо облаке для вашей собственной инфраструктуры только для части CI.
Tekton
Tekton... Ну... Это еще один CI)))
Ключевые особенности:
Можно запустить его в кластере K8s
Определить пайплайны как нативные ресурсы K8s, и просто применять применять их kubectl.
Теперь у него есть панель инструментов и интерфейс командной строки.
Кроме того, Tekton позволяет создавать, тестировать и развертывать в нескольких средах, таких как виртуальные машины или бессерверные решения. Вы также можете выполнять развертывание в различных облачных провайдерах или гибридных средах, используя конвейеры Tekton.
Стоит ли использовать его? Мое мнение, если:
Вы должны «владеть» своей системой CI (например, использование бесплатной квоты GitHub Actions по какой-то причине вам не подходит).
Вы уже используете K8s.
Вам нравится работать с K8s.
тогда определенно стоит попробовать Tekton.
HashiCorp Harness
Harness. О, это у нас еще один CI. НО на самом деле куда больше чем просто CI.
Оно объединяет несколько вещей в одно:
CI
CD/GitOps
feature flags
cloud costs
Harness предлагает размещенные виртуальные машины (ВМ) для запуска ваших сборок. С Harness Cloud вы можете без проблем создавать свой код на инфраструктуре, которую предоставляет Harness. Вы можете тратить меньше времени и усилий на обслуживание инфраструктуры и вместо этого сосредоточиться на разработке отличного программного обеспечения.
В Harness непрерывная доставка моделируется с использованием конвейеров и этапов. На каждом этапе вы определяете, что вы хотите развернуть с помощью служб, где вы хотите развернуть это с помощью сред и как вы хотите развернуть это с помощью шагов выполнения.
Harness GitOps позволяет выполнять развертывание GitOps в Harness. Вы определяете желаемое состояние службы, которую хотите развернуть, в своем манифесте Git, а затем используете Harness GitOps для синхронизации состояния с вашим работающим кластером Kubernetes.
Harness Feature Flags (FF) — это решение для управления функциями, которое позволяет вам изменять функциональность вашего программного обеспечения без развертывания нового кода. Это позволяет вам скрывать код или поведение без выпуска новых версий программного обеспечения. Флаг функции похож на мощный оператор if.
Короче говоря, если вы хотите, чтобы SaaS CI/CD/FeatureFlags были собраны в одном месте, это то, на что стоит обратить внимание.
Thanos
Здесь для начала следует немного вспомнить о локальном хранилище Prometheus.
Локальное хранилище Prometheus не предназначено для долговременного хранения; внешние решения обеспечивают длительное хранение и устойчивость данных.
Несмотря на то, что мы можем установить длительный период хранения данных, например годы, с помощью storage.tsdb.retention, вопрос остается в масштабе и планировании. С годами зондов с высоким разрешением обработка очень длинных запросов может занять много памяти. Это также зависит от масштаба: например, функция rate() в течение одного года с 15-секундным интервалом очистки требует 2,1 миллиона выборок или около 2,6 МБ данных. И это только по одному показателю.
Если у вас небольшая инфраструктура, нет ничего плохого в том, чтобы скорректировать время хранения до нескольких лет; текущая реализация TSDB отлично справляется с этим. Для более крупных приложений рассмотрите возможность использования более крупной распределенной базы данных TSDB.
И Thanos — это решение, которое решает эту проблему: это высокодоступная установка Prometheus с открытым исходным кодом и возможностями долгосрочного хранения, ориентированная на долгосрочное хранение. Если вы уже столкнулись с проблемами с хранилищем Prometheus, попробуйте Thanos.
HashiCorp Sentinel
Наконец поговорим про Sentinel.
Политика как код — это подход к управлению политиками, при котором политики определяются, обновляются, совместно используются и применяются с помощью кода, и Sentinel — это решение HashiCorp.
Поскольку Sentinel принадлежит HashiCorp, он хорошо интегрируется с другими продуктами HashiCorp. Так что, если вы активно пользуетесь Terraform, Vault, Consul или Nomad и хотите попробовать Policy-as-Code, Sentinel — именно то, что вам нужно.
Чтобы привести несколько конкретных примеров того, что могут сделать политики Sentinel:
Не позволяйте облачным ресурсам предоставляться без тегов с помощью Terraform.
Убедитесь, что изменение важных данных Vault может выполняться только авторизованными системными операторами с действительным MFA.
Разрешить рабочие нагрузки Docker только в Nomad.
Ключи Consul можно обновить только в рабочее время.
Пример короткого кода:
import “tfplan/v2” as tfplan
aws_instances = filter tfplan.resource_changes as _, rc {
rc.mode is “managed” and
rc.type is “aws_instance” and
rc.change.actions is not “delete”
}
main = rule {
all aws_instances as _, instance {
(instance.change.after.tags else {}) is not empty
}
}
Довольно очевидно, не так ли?
Помогите откатить Kali Linux на винду
Acer Aspire 3
В общем когда то давно поставил себе кали, хотелось освоить навыки маминого хакера, ахха, но не пошло
Недавно подумал, что пора откатывать обратно на винду, но когда записал образ через команду dd, то флешка пропала с биоса(сам ноут ее видит), какие бы махинации я не проводил, она не возвращается, возможно причина в файлах образа «на замках»(ридонли), но тогда напрашивается вопрос как их снять. Пробовал:
chmod 0777 -R ~/флешка
sudo chown -R user ~/флешка
Бесполезные махинации, которые успехом не увенчались, может я сделал что-то неправильно? Помогите разобраться с откатом пожалуйста.. И прошу объяснять как чайнику, ибо им и являюсь, ахах, всем спасибо! Лучший вариант с моим интернетом(≈130кб/сек) решить что-то с тем, что имею без доп. скачиваний.
Постигая основы бэкенда и системного администрирования в бухгалтерии
Случилось это так, шо я случайно залетел поработать в одну банковскую контору (ну как поработать, на данный момент я предоставляю им консультационные и не очень услуги по автоматизации процессов, сетевому администрированию, и прочим всяким таким ИТ-штукам), нулевой отправной точкой было то, что меня нашел какой-то чел из этой компании через общих знакомых.
День 0: В самом начале
В самом начале всего этого действа, мне позвонил этот чел, и предложил пообщаться, типа как собеседование, но для этого нужно было подъехать к ним в офис. С одной стороны - нужно было чуять неладное и сливаться (есть же всякие зум-конфы, или банальный созвон в телеге или просто по телефону), я же пожал плечами и поехал к ним. Из разговора было примерно понятно, что у них то ли уволился разраб, который работал с этой херней и им нужен человек, который в этом разберется и будет дальше работать, то ли они ищут человека, который сможет это понять, сделать рефакторинг или переписать на другом движке, под навыки тех сотрудников, которые у них имеются, это было максимально размытое определение, чуть даже более чем, но, как ни странно, я согласился.
День 1: Завтра я буду у тебя в офисе, и мы начнем сортировать эту кучу
Спустя неделю игры в молчанку, этот чел все же со мной связался, и, к моей неожиданности (я максимально на такое не рассчитывал), сообщил мне, что они готовы дать оффер, ну и пообщаться чуть более детально. Подъехал, заключили какой-то договор, типа как оказания услуг, хотя намекали на то, что хотят все же устроить по ТК (ох и не дурак же был, шо отказался), договорились на завтра перейти к деталям и обсудить фронт работ, попрощались, и я поехал заниматься своими делами.
Собственно, в этот момент (уже) немного терзали некоторые вопросы, уровня того, что
День 2: А можно бумажку на бумажку?
Собственно, в этот день я понял, шо именно я в этой жизни сделал не так. Сие место оказалось той еще конторой пидорасов, в основном, вплане того, то они ОЧЕНЬ любят всякую бумажную хуету, и ОЧЕНЬ любят всякие бюрократические заёбы, чем, собственно, усложняют себе жизнь чуть более, чем полностью.
Большая часть прикола в том - что мне на собеседовании (если это можно так назвать), заливали редкостную хуйню типа "ДА МЫ СОВРЕМЕННЫЕ, МЫ РАБОТАЕМ ПО АГИЛЕ-МЕТОДОЛОГИИ, МЫ ПРОГРЕССИВНЫЕ ДОХУЯ, НУ ДА, АГА"
Что, собственно, ни коим образом не билось с тем, что я увидел на практике.
По факту - меня трудоустроили, каким-то околоразрабом-сисадмином-комплюхторщиком, следовательно, исходя из специфики работы - должен быть доступ ко всему, с чем я буду (и, теоретически, мог бы) работать.
А оттута начинается самое интересное:
День 3: Толик-еболик, первый день на работе
Собственно, мне сказали шо настроили учетку/доступы/остальной фарш, и я могу выходить раковать в офисе и работать работу на работе за деньги. Радостный аки малолетний еблан я приперся в офис посмотреть, собственно, а че каво, и тут же столкнулся с некоторого рода дерьмом:
Мне обещали доступ в енторнеты, однако, под доступом в енторнеты подразумевалось главная страница гугла, и, если что-то нужно найти, то это придется отдельно согласовывать (КАЖДЫЙ РЕСУРС В ЕНТОРНЕТЕ, КАРЛ!)
В принципе, сведясь к тому, что гуглить, в целом, можно и с телефона, закрыл на эту хуйню глаза, и пошел подключаться на сервак, к которому, к моему превеликому удивлению, доступа нихуя не было - для того чтобы дали доступ, необходимо было опять отдельно писать каким-то мудакам из СБ, и объяснять душным бюрократическим языком, нахуя оно вообще тебе надо (ПО АГУЛЕ-МЕТОДОЛОГИИ ОНИ РАБОТАЮТ, АГА, НУ ДА)
Еще один базово-кринжовый момент: если работающий продукт важнее исчерпывающей документации, то может быть и наоборот - однако, пройдя семь ебучих кругов ада согласования бумажек на бумажки, я столкнулся с нахуй поваленным продом, и с полным отсутствием к нему данных.
День 4: А может быть уже к делу?
Итак, проваливаясь на сервак, первым делом я вижу такое:
Думаю, не имеет смысла напоминать о том, шо на дворе шел 2023 год
Проваливаясь в технологический стек того дерьма, на чем, собственно, написан код, степень моего ахуя возрастала, равно столько же, как и количество вопросов, а какого хуя и оно до сих пор живое, поддерживается, и работает
Итак, вашему вниманию предлагается:
ОС на железе:
Windows Server 2008 R2 - выпущен в 2009, поддержка закончена в 2020 году;
Веб-морда: HTML+CSS+JS, но максимально примитивный, JS, например, версии ES5
Начинка на бэке - тоже полный пиздец, однако
PHP 5.3 - подозрительно, но тоже вышел примерно в 2008-2009 году
C++ - ориентировочно также, года 2008-2010, однако возникает вопрос - нахуя, а главное зачем
ASP.NET 3.5 - опять же, 2008 года выпуска, но хуй его знает, зачем оно вообще нужно (фактически, мы приклеиваем веб-морду к базе данных, не более того, возможно, для поддержки б-гомерзкой виндой, однако, кажется, для меня это навсегда останется тайной)
В связи с этим, возникает некоторое количество вопросов:
1. А что мешало впилить сервак на LEMP, например, один раз его настроить, и не париться с ним до конца своих дней?
2. Переписать бэк на питоне/РНР, и сделать это без всяких дополнительных извращений
3. Интересно, а они в курсе, что стек тоже можно обновлять, примерно с таким же уровнем сложности (нет), как обновить приложение на айфоне?
4. Среда разработки - это отдельная категория пятикратно переваренного кала - у них до сих пор стоит Visual Studio 2008 и блокнот в винде, как основные средства разработки, да, ага.
День 5: Игорь, а может быть ну его нахуй?
Собственно, весьма ожидаемой концовкой событий было то, что я сьебался с этого гадюшника. Действительно, в конторе, где перекладывание бумажек занимает примерно 60% твоего времени, царит бюрократия, геронтократия и кумовство, вряд ли найдется место интересным проектам и работе по душе.
З.Ы. Они кстати находятся в данный момент в поиске Fullstack Backend разработчика эту дичь, за 600 долларов в месяц, с работой строго из офиса, если вдруг есть мазохисты кому может это показаться интересным, могу поделиться ссылкой на вакансию)
Как мы сервак пилили (длиннопост)
Жизнь шла своим чередом, до того момента, как я не увидел его:
К слову сказать - не особо сильно помню, как он появился - вероятнее всего, это было году в 2018 при закрытии типографии, в которой ранее работал Евграф, но это не точно.
Дальше-больше: около месяца назад мы с командой пришли к выводу, что имеется необходимость сразу по нескольким причинам:
Хранение файлов на одном устройстве, не на разных компах / в облаке / другое;
Возможность создания открытого интернет-ресурса;
Использование данной машины как песочницы - в разрабно-тестовых целях.
А что там по МПХ, товарищи?
При вскрытии заглянуть под капот, например:
MB: Supermicro X8;
CPU: 2X Intel Xeon X5690 - 6-Core, 3.46GHz, LGA1366;
RAM: 1X 4GB DDR3 1866 MHz;
No HDD;
Действительно, ситуация немного удручает. Как понимаем - ранее оно использовалось исключительно для хранения файлов на локальном устройстве, но не более того.
Пациент скорее мертв, чем мертв.
Итак, что мы имеем на этом этапе?
Практически ничего. При вскрытии обнаружили, что в блоке чуть больше чем полностью отсутствуют вертушки, радиаторы, и прочие части тела (например, кабеля до дисковой панели, перетертый провод от матери до панели питания, и прочие "приятные" бонусы).
В связи с этим в голову стукнул весьма резонный вопрос:
Однако нет, таки мы не пальцем деланные, поэтому решили прикинуть палец к носу, на предмет плана задач по этой туше.
Первое что нас интересовало - живо ли то, что уцелело, однако, проверить сие возможности не совсем имелось - методом Ивана Тыка мы пришли к выводу, что блок питания накрылся пиздой по всей вероятности, выработал свой ресурс. однако нас ждала немного другая подлянка, про которую упоминалось ранее - убитый кабель от мамки до кнопки включения.
Далее в дело пошли максимально кустарные идеи:
Да, на этапе использования коннектора от мака мы и сами поняли, что мы те еще ублюдки
Весьма странный момент - но даже при замене проводов, оно отказывалось работать. З.Ы. Не считайте нас ублюдками, мы потом спаяли нормальный коннектор.
По итогу - проблему решило подключение другого БП вместо того, что имелся в корпусе, что еще раз подтвердило наши домыслы.
И ВУАЛЯ - ОНО РАБОТАЕТ!
Утро начинается не с кофя
Итого, на данный момент имеем себя что:
Полудохлый, но все-таки живой сервак;
Несовместимые детали;
Танцы с бубном.
На этот момент Евграф пошел решать вопросы материально-технической части - например, облазить борды на предмет радиаторов и вертушек (снизу на фото):
Так скажем, цена на них кусалась - по 12 баксов за вертушку / по 20-25 баксов за железку, поэтому весьма недурно было бы проявить навыки хитрожопости для того, чтобы выбить необходимый лут.
Мы же, тем временем, пока Евграф бил баклуши занимался крайне полезным делом, осознали, что вот он - наш друг и товарищ на ближайшие несколько часов:
Когда я был маленьким, дед говорил мне, что это такое орудие для пыток
Собственно, что было решено сделать:
Имелся блок на 850 ватт, что должно было чуть больше чем с запасом хватить на питание сего ящика, + подключения в него прочих инородных тел вроде видеокарты для просчета 3D/машинного обучения/прочих неигровых приколов, и корпус от блока на Mac Pro, который идеально влезал в корпус.
В процессе вивисекции. PIC1 - выпаян из мачка, PIC2 - впаян в мачок и установлен в тушку
Дело сделано, поэтому можно бы и сделать небольшой перерыв на полдник:
Плюшки, вертушки, и ещё много чего.
Танцы с бубном с паяльником подошли к концу, тем временем Евграф вернулся с недостающими железками, на которые, по его словам, он потратил что-то около 60 баксов за все вместе взятое:
Итак, окончательная конфигурация на данный момент такова:
MB: Supermicro X8;
CPU: 2X Intel Xeon X5690 - 6-Core, 3.46GHz, LGA1366;
RAM: 8X 8GB DDR3 1866 MHz, Quad-channel ECC-REG;
HDD: 4X 2TB WD Purple;
POWER: 850W Zalman Acrux ARX 80+ Platinum;
Собственно, само железо, в т.ч. в рабочем состоянии, настроенное, и готовое к труду и обороне выполнению задач имеется, осталось его подключить и настроить. В теории - нужен какой-нибудь интерфейс, вроде KVM, но цена на их, мягко говоря, кусается:
Возможно, мы сможем позволить себе когда-нибудь такую штуку, хотя, по нашему мнению, это выглядит весьма нецелесообразно и экономически невыгодно по нескольким причинам:
Дорохо. Да, это около косаря баксов за новый и ~125-300 за б/у вариант
А зачем, если мало железа? - Да, у нас небольшой объем хлама в шкафу, мы рассматриваем это дело как эксперимент, т.е. делаем исключительно для лулзов и получения приятного (и не очень) опыта
Есть и другие, более дешевые варианты
Например, вот этот красавчик:
Собственно, как мы подошли к решению данного вопроса:
Вместо стильно-модно-молодежной дорогущей KVM расчехлили стандартный набор из клавы, мышки и 17" монитора Samsung 740BF, которому сто лет в обед. Дешево и сердито железо свои задачи выполняет, затраты практически равны нулю. Вместе с этим в рэк въехала выдвигающаяся полка, на которой все это добро и крепилось. Дешево и сердито, как говорится. Остался только один вопрос:
А шо с сетью?
Действительно, вопрос хороший, это же надо куда-то подключить, чтобы работало, а иначе весь смысл теряется. Тут я случайно вспомнил про это:
Железка в настройке до одури простая - одна дырка для входного провода, остальные для выходных, все изначально работает из коробки. Обзор и подробное описание, а также процесс настройки на уровне "для хомячков" - тут.
Вообще, мы не любим хлам в проводах чуть более чем полностью. Так что с этим также придется повозиться.
Итак, что мы имеем на текущий момент: собранное железо,, и на минимальном уровне настроенный сетевой хаб.
И, по логике вещей, следующий шаг - установка оси на железку, для того чтобы она не пролеживала полку в шкафу где-нибудь на балконе. Свой выбор мы остановили на Убунте, причин тому несколько:
Это "детский" дистрибутив, понятный на минимальном уровне - к вопросу того, что "а что лучше - Debian или CentOS" - много гайдов, не требуется особо специфических знаний;
Хорошая поддержка ОС и большое количество ПО;
Логически понятный набор команд
Процесс установки, понятное дело, мы описывать не будем, он и так логически понятен (возможно, касаемо более тонкой настройки когда-нибудь напишем статью-другую), на выходе получаем примерно вот это:
Итак, все живое, все работает.
Шутки ради, решили установить MacOS на другой диск, однако, она отказалась запускаться без совместимого видеоускорителя - чисто теоретически, мы когда-нибудь, возможно, с этим тоже поиграемся.
Ближе к телу: Зачем усложнять простое, если можно упрощать сложное?
Собственно, изобретение велосипеда в этом и заключалось - зачем юзать KVM, если можно просто подключиться к сервачку, который пылится где-то там, и особо не сильно мешает? Мы, как весьма ленивые в такого рода моментах люди, придерживаемся следующего правила:
Один раз настроил -
и потом ебешься с этим до конца жизнии оно само дальше спокойно себя работает
Для этого было предложено использовать виртуалку, и подключаться через нее к имеющемуся серверу.
ДИСКЛЕЙМЕР: ДАННЫЕ РЕКОМЕНДАЦИИ НЕ СООТВЕТСТВУЮТ ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ИСПОЛЬЗУЕМОГО ПО, ПОЭТОМУ ЕСТЬ ВЕРОЯТНОСТЬ, ЧТО ЧТО-НИБУДЬ ДА ОТЪЕБНЕТ, ПОЭТОМУ АЛЬТЕРНАТИВНЫЙ ВАРИАНТ - ПОДКЛЮЧАТЬСЯ ЧЕРЕЗ SSH, НАПРИМЕР
Вариант, который будем использовать - VMWare Horizon. В целом, подробная и исчерпывающая инструкция имеется на сайте по ссылке выше, но вполне резоннен здесь весьма риторический вопрос - а читает ли кто-нибудь вообще документацию перед тем, как использовать ПО? Вот, ну и мы нет.
Как итог, что имеем на текущий момент - уже рабочие настроенные железки с ПО, с которыми уже можно работать. А как подключить удаленку и развернуть сервер - об этом мы позднее ещё расскажем.
Поиграем в бизнесменов?
Одна вакансия, два кандидата. Сможете выбрать лучшего? И так пять раз.
Мой сервис удаленного доступа. Обновление 1
Всем привет! Я знаю, что немного вылетел из информационного поля, в этом посте хочу рассказать почему и что изменилось в сервисе за последнее время.
Прежде всего хочу поблагодарить тех людей, что проявляли активность, кто добавился в группу (нас уже около 360 человек), и особенно тех, кто выразил заинтересованность проектом и поддержали словами, именно ваш интерес и побуждал меня продолжить разработку.
Так же не могу не поблагодарить всех пикабушников, кто выкладывал мало постов или воздержался от этого, благодаря чему я не задерживался в прокрастинации и смог сосредоточиться на работе. Особенно радует переход из горячего прямо в свежее, что бы я без этого делал.
Спустя неделю после публикации статьи мне прилетело много багов, прикинув примерное время, требующееся на их устранение, прибавив к этому время необходимое для реализации тех возможностей, что были в планах, а так же учитывая, что Python язык больше скриптовый, мало подходит для тиражируемого релизного приложения, особенно учитывая компилируемый размер файла и меньшую производительность, я пришел к выводу, что рано или поздно это всё придется переписывать на другом языке, а это большие затраты времени, и чем дальше бы я зашел, тем больше бы вложений потребовалось, а учитывая что финансирую разработку только я сам, это могло бы вылиться в стагнацию или вообще повлиять на жизнеспособность сервиса.
Давайте теперь вернемся в настоящее. И вот спустя примерно пять недель работы, пару бутылок виски и четыре дня в депрессии, я все таки переписал клиента программы на более низкоуровневом языке, который пришлось изучать с нуля, попутно лысея. И как по мне - получилось весьма неплохо, давайте расскажу подробнее.
Начнем с самого частого, на что обращаешь внимание - размер программы, для сравнения:
Windows, было 58,6 мб, стало 3,3 мб в консольном варианте и 6,1 мб с GUI. Разница в 17,7 раз!
Linux, было 233,6 мб, стало 7,5 мб. Еще большая разница в 31,1 раз!
MacOS, ничего не изменилось, потому что клиента для неё пока нет. Но я увидел проголосовавших в группе по этому вопросу, буду его прорабатывать.
Конечно еще можно считерить и упаковать файл в zip архив, тогда размер получается 1,79 мб, это примерно 32,7 раз. Моя небольшая победа.
В windows пришлось разбить программу на две версии, т.к. можно скомпилировать или консольное или графическое приложение, изначально была задумка запускать консольное при наличии соответствующего аргумента. Объединить можно, но это займет время и добавит сложности в разработке.
Вот скриншоты интерфейсов, в консольном варианте он стал попроще:
По производительности тоже есть изменения. Потребление памяти при обновлении процессов в новой версии 37 мб против 70 мб в старой. На первый взгляд все открывается быстро, хоть это сейчас и не сильно важно, но при требовательных операциях в будущем будет конечно ощутимо в сравнении с Python.
Сервис стал доступнее для большего количества версий операционных систем, например я понизил архитектуру до x86, и минимальная поддерживаемая версия на которой тестировалась программа — windows 7, а для linux — ubuntu 18. Правда обе доступны только в консольном варианте, в графическом режиме отказывалось запускаться, думаю потом поменяю на другой GUI фреймфорк. Для более новых версий windows всё осталось так же.
Еще сделал наверное самую нужную функцию на текущий момент - автоматическое обновление, что бы не пришлось ручками переставлять на каждой машине, особенно если у вас много станций.
Так же были внесены небольшие изменения:
Исправлен баг с открытием окна командной строки на пару секунд при выполнении команд и при запуске.
Не всегда отображались IP адреса, особенно на linux.
Баг с отключением сервиса программы через 3 дня, из за чего станции были в офлайне. Никто об этом не написал, но я исправил.
Вывод результата кастомной команды теперь более приближен к оригинальному.
Генерация пароля каждый час, если он не был задан вручную.
Поправлена немного админка.
Было еще много изменений по мелочи, из того что успел прочитать в чате проекта и в личке, которые делал буквально на лету, не записывая.
Немного изменил логику, в том числе взаимодействие между клиентом сервером, поработал с безопасностью последнего, так что Python версию нужно будет заменить на новую.
По правде говоря, чистая работа с кодом сама по себе заняла около 3 недель, а последние две ушло на сборку и отладку под разные дистрибутивы, и на каждом встречались свои ошибки, и когда я закрывал ошибку скажем на ubuntu 22, на 18 вылазила новая. Меня это печалило до такой степени, что по ночам снились кошмары, например где я нахожу баг, но не могу его описать, не могу найти логов, хотя четко понимаю и вижу как приложение крашится, или еще сон с бесконечной сборкой, когда запускаешь команду и ждешь, ждешь, ждешь и больше ничего делать не можешь, просыпаешься в холодном поту и приходит радость, что это всё не в заправду. Для справки - мне обычно снились приятные или нейтральные сны, которые я часто забывал проснувшись, но эти я помню до сих пор.
Ну еще немного выскажусь, если вы не против. Хоть переписывать было и интересно в технологическом плане, но всё же я немного приуныл, так как мне хочется реализоввывать новые фишки, и удивлять вас ими, а так получается я делал всё одно и то же. В планах было запустить релизную версию уже на шестой месяц проекта (сейчас), и получать хоть какую ни будь отдачу, что бы были деньги раскручивать проект, а не двигаться со скоростью черепахи. И единственное что меня мотивировало — это ваши добрые пожелания и отзывы, которые показывают потребность в этом сервисе, только благодаря им я сделал спринт и выпустил это обновление раньше, чем работая в нормальном темпе.
Итак к делу, что бы обновиться на новую версию — нужно удалить старую, скачать новую и установить. Что бы ID станции и привязка к вашему аккаунту сохранились — переместите файл config.json из "C:\ProgramData\Cusco\CuscoRemoteControl" в "C:\ProgramData\Cusco\RemoteControl"
Новые файлы уже залиты на сайт, находятся в разделе загрузки.
В ближайшем будущем начну работу над визуальным управлением, попутно реализовывая ваши пожелания, если будет время.
Всё так же было бы классно увидеть ваши результаты тестирования, если можно то со скриншотами и подробностями как воспроизвести найденную ошибку.
Спасибо за ваше время, жду вас в группе. Обращу внимание, что в ней есть подгруппы: баги, основная — для общения, и идеи — которую в скором времени подчищу от флуда.