Photo by Kevin Horvat
Все 12 лет своей карьеры я работал с .NET и был крепко привязан к Windows и проприетарным инструментам разработки. Но, спасибо Microsoft, .NET Core все изменил и теперь разрабатывать для .NET можно почти на чем угодно и в чем угодно. Дело за малым — перетащить на Core свои проекты. Не так давно я решил и этот вопрос и завел трактор для полного переезда на Ubuntu.
Результат очень понравился — все взлетело, разрабатывать легко, а Docker и Kubernetes сделали процесс переезда намного легче. Но из-за слабого знания ОС, bash и запутанности вариантов установки некоторых инструментов (например, того же Docker) изначальная настройка заняла больше дня. То есть процесс довольно долгий и местами запутанный.
Дабы сэкономить время будущему себе и тем, кто также планирует попробовать разработку под Linux, я оформил все в виде скриптов. Их можно запустить на чистой Ubuntu и они все настроят пока ты сидишь и пьешь чаек. Также, при желании, их легко допилить под свои нужды.
Если для вас это звучит полезно — добро пожаловать под кат.
Скрипты доступны в репозитории на Github. Для их чтения достаточно начального знакомства с bash и они обильно снабжены ссылками. А человек искушенный, скорее всего, найдет в них и неоптимальные моменты (если нашли — сообщите мне, пожалуйста, буду очень вам благодарен).
Полагая, что скрипты будут чаще «дотачиваться» под конкретные нужды, чем использоваться в исходном виде, все тонкие моменты (например, как запустить команду из под текущего пользователя находясь в режиме sudo) также снабжены ссылками.
Итоговый набор состоит всего из пяти файлов — три скрипта и два конфига для kubernetes.
1_opinionated.sh
Простите, но первый же скрипт это главный кандидат на «дотачивание», а то и вовсе пропуск.
Прежде всего, он устанавливает гипервизор для дальнейшего запуска kubernetes. Я выбрал Virtualbox, но также возможен запуск на KVM и вообще без гипервизора. Каждый вариант имеет свои нюансы, поэтому финальный выбор за вами.
Также скрипт устанавливает поддержку русского языка (чтобы я смог написать эту статью).
После запуска необходимо выполнить перезагрузку, чтобы Virtualbox смог себя донастроить перед установкой остальных инструментов.
2_setup.sh
Самый большой и полезный скрипт. Он устанавливает следующие инструменты:
- Git
- .NET Core 3.1 SDK
- Nodejs
- Docker Community Edition, добавляет репозиторий для обновлений Docker
- Проверяет что установлен Virtualbox или KVM и устанавливает minikube
- Устанавливает Visual Studio Code и несколько расширений для разработки как frontend, так и backend: Gitlens, TSLint, Prettier, Stylelint, C#, Docker tools, Kubernetes tools, Kubernetes Support.
3_configure.sh
Выполняет настройку установленных тулзов. А именно:
- Запрашивает имя и email пользователя Git
- Опицонально предлагает установить VS Code как редактор по умолчанию для Git
- Опционально предлагает использовать libsecret для сохранения паролей Git в зашифрованном виде
- Добавляет текущего пользователя в группу «docker», необходимую для работы с Docker без постоянного использования sudo
- Стартует minikube и устанавливает dashboard для доступа к кластеру через Web UI
- Создает в minikube пользователя-админа для доступа к дашборду. Для этого используются файлы minikube_admin_user.yaml и minikube_role_binding.yaml из репозитория.
- Выводит инструкции по получению токена для доступа к дашборду.
Чтобы применились настройки доступа к docker необходимо разлогиниться и перезапустить сервис docker. Или попросту перезагрузить ОС.
Вот, собственно, и все. Надеюсь, скрипты будут полезны желающим быстро освоиться с Ubuntu и разработкой под .NET Core.
Комментарии (35)
AlexDevFx
06.12.2019 22:26+1Также занимаюсь разработкой под .NET в Kubuntu. Понравилось, что докер завел в полпинка в сравнении с виндой. VS Code конечно же проигрывает Visual Studio в качестве инструмента под .NET. Перешел на Rider, благо он работает под Linux, плюс быстрее, чем решарпер.
rv82
07.12.2019 08:29Перешел на Rider, благо он работает под Linux, плюс быстрее, чем решарпер.
Прошу прощения, а как вы решаете проблему лицензии? Покупаете? Или ломаете? Мне что-то совесть не даёт пользоваться ломаным продуктом. А цена на него никак не радует. Поэтому под linux'ом использую VSCode. Хотя работу в ней удобной не назовёшь. Да ещё и OmniSharp приходится периодически перезапускать, т.к. в какие-то моменты он начинает подглюкивать.
fshchudlo Автор
07.12.2019 09:01Тоже пользуюсь Rider+Resharper на винде (Rider в первом скрипте даже записан, но закомментирован как платный), лицензионными. Только что посчитал — один рабочий день с этими инструментами стоит мне 27 рублей. Как проезд в маршрутке или пачка жвачки. Имхо, это отличная цена за получаемые комфорт и продуктивность.
faoriu
07.12.2019 13:18Поэтому под linux'ом использую VSCode. Хотя работу в ней удобной не назовёшь
Странно: а по результатам недавнего опроса на StackOverflow больше половины разработчиков предпочитают именно VSCode
kekekeks
07.12.2019 14:45+1В качестве альтернативы там из бесплатного только MonoDevelop, в котором для .NET Core не работает отладка. По желанию левой пятки M$FT.
kefirr
07.12.2019 22:57+1Rider себя окупит очень быстро даже для джунов (потому что научит много чему). VSCode и рядом не валялась. Не стоит экономить на рабочих инструментах.
Плюс, полученный опыт транслируется на все остальные продукты, если придётся работать с Python, Java, Go, PHP.
faoriu
08.12.2019 12:06В любом случае VSCode будет быстрее и гибче развиваться как свободный продукт + в долгосрочной перспективе лучше ориентироваться на популярные инструменты.
fshchudlo Автор
08.12.2019 12:26VS Code действительно быстро развивается, но как редактор общего назначения, годный для всего подряд, неспециализированный.
Любая «заточка» его под конкретные нужды (тот же C#) делается через расширения. Такая модель имеет ограничения, потому что правила игры определяет сам редактор кода и они должны оставаться универсальными, подходить всем плагинам.
Скорее всего, мы никогда не увидим такие возможности анализа, рефакторинга, автоисправлений, контекстных действий как в Rider и в той же Visual studio. А также штуки вроде дизайнеров DbContext-ов и прочие.
Полагаю, что все больше функционала будет перекочевывать в консоль. В dotnet CLI уже есть шаблоны проектов, работа с зависимостями, сборка, публикация, запуск — все через консоль вместо кнопок на UI.
И полноценным IDE в этих условиях всегда будет место и на них будет спрос. И, скорее всего, они так и будут платными именно за свою оптимальность и продуманность для конкретных задач.
kefirr
08.12.2019 16:44в долгосрочной перспективе лучше ориентироваться на популярные инструменты
С такой логикой можно на JavaScript или Python перейти c дотнета, они ведь популярней :)faoriu
08.12.2019 21:45Отсутствие крупного игрока, который будет поддерживать и развивать стандарты в долгосрочной перспективе, сыграло с JavaScript злую шутку. Оказалось, что даже COBOL даёт более стабильное и выгодное трудоустройство :)
cup_of_tea_1
09.12.2019 12:02Поделитесь статистикой про COBOL в сравнении с Javascript. По моим источникам в случае со вторым трудоустройство вполне стабильное и выгодное.
AlexDevFx
08.12.2019 10:54Я купил лицензию. И не пожалел. Удобство в разы повышается в сравнении VsCode+OmniSharp. Встроенный клиент клиент БД по сути тот же datagrip. Мне показалось что сам Rider быстрее чем Reshaper
mrobespierre
07.12.2019 07:38+1Спасибо за статью. По-моему одного маленького шажка не хватило — Ansible. Скрипты делают своё дело, но это инструмент прошлого тысячелетия (тогда софт был заметно проще, его было меньше, open source и коллаборация были на совершенно ином уровне), поддерживать чужой плейбук проще простого, а вот скрипт уже кому как.
fshchudlo Автор
07.12.2019 07:43Отличная мысль, спасибо) мне как-то в голову не пришло. Попробую как с ним заведётся.
megasuperlexa
08.12.2019 11:06А это вообще про то? Вроде же нет задачи менеджерить сеть из 10+ компьютеров, а просто настроить себе рабочую машину?
mrobespierre
08.12.2019 15:02А Ansible и не требует 10+ хостов. Зато иногда надо рабочую машину переустановить (новое железо например).
Установка чего-либо скриптом не гарантирует идемпотентности, а Ansible'ом гарантирует, поэтому имеет смысл предпочесть его.
V4L1K
07.12.2019 13:25Спасибо за статью, я даже не догадывался что .NET теперь не привязана только к винде
chupasaurus
07.12.2019 14:29+1Например, без гипервизора Minikube будет запускать свои компоненты прямо на хост-машине и потребует установки устаревших пакетов Docker
Например, в виртуалке тоже будут устаревшие пакеты Docker?
Есть snap-пакет microk8s от Canonical, да и в конце концовkubeadm initхватит всем (ну ладно, ещё поставить CNI и сделать ноду рабочей, документация).
megasuperlexa
07.12.2019 17:52а можно общий вопрос? я понимаю зачим ЗАПУСКАТЬ дотнет на линуксе, но зачем РАЗРАБАТЫВАТЬ на нём же? в чём были плюсы ухода со знакомой платформы именно для разработки-дебага?
fshchudlo Автор
07.12.2019 21:08+3Вы знаете, ответ на этот вопрос почти философский и сугубое имхо.
У меня за время работы в индустрии сложилась примерная такая картина:
Изначально была куча технологий, и вокруг каждой было свое сообщество, которое самостоятельно развивало свою экосистему.
Дальше активное развитие получил open source. И уже не просто библиотечки, а огромные инструменты. Те же Google и Netflix сделали гигантский вклад в инструменты continuous delivery. И множество сообществ объединилось вокруг этих инструментов. На мой взгляд, объединились уже все, а Microsoft-сообщество (не сам Microsoft, а его сообщество) стоит несколько в сторонке и за проприетарные инструменты держится: Visual Studio, Powershell, Azure DevOps, SQL Server, и, конечно, Windows.
Еще можно на Cloud Native Landscape посмотреть. В каждой категории множество инструментов, альтернатив. В большинстве бесплатное и open source Но, если отфильтровать по Microsoft, то останется совсем немного и все прямо или опосредовано (через Azure) платное. Я тут оговорюсь — я совершенно не против чтобы Microsoft зарабатывал, тем более что многие из его инструментов действительно отличные. Но один и платный инструмент, привязанный к экосистиеме — это ограничение. И сам же Microsoft все больше вливается в общий движняк. Linux уже не только в Azure живет, но и WSL прямо в Windows работает. А недавно Microsoft объявил, что Windows для них больше не стратегический продукт и его роль в бизнесе компании будет снижаться.
Если Microsoft таким путем идет, то и разработчикам, на мой взгляд, стоит в ту же сторону посмотреть, а не позади плестись.
Второй момент заключается в том, что некоторые важные вещи на Linux просто лучше работают (контейнеры). Также нередко какая-нибудь open source библиотека (во фронтенд разработке спотыкался об это не раз и не два) полезная, хочешь фичу запилить. Но на windows ни собрать, ни тесты запустить не можешь. Потому что разработчики на Linux/Mac сидят и тулинг у них свой. А для тебя Linux это барьер.
И третий момент заключается в том, что выучить новый язык программирования, например, python или scala, чаще всего совсем нетрудно. На это нужно буквально пару недель. Ну ладно, чтобы неплохо освоиться — пара месяцев. Но вот ты узнал новый язык, он тебе понравился и это твое. Устраиваешься в классный стартап. Но Scala-то-Scala а работают там в линухах, на bash, глубоко знают весь тулинг. А с этим уже не так просто освоиться и быстро начать продуктивно работать. У меня вот вообще был такой эффект, что я в Rider первые месяцы не мог делать действительно сложные задачи. UI непривычный, цветовые схемы, шрифты — внимание постоянно на них отвлекается и я не могу работать на пике. Кастомные темы цветовые перебирал — без толку. Просто со временем привык, но это время понадобилось.
В общем, главный барьер это не язык, а тулинг. И я не вижу причин не перескочить этот барьер и не влиться в большое, единое, в основном бесплатное и open source сообщество да еще и повысить свою востребованность на рынке труда. Тем более что и Microsoft уже вовсю поддерживает Linux.
Сейчас у меня стоят параллельно Ubuntu и Windows и я спокойно осваиваюсь. Изначально старался работать в Ubuntu, если уперся в незнание — перескочил на винду и продуктивность по текущей работе не теряю. А нужные знания позже подтягиваю. На текущий момент на Ubuntu работать уже банально удобнее.
funca
07.12.2019 22:13Вы сравнивали перформанс .Net приложения при запуске под Windows и Linux? С такой разницей надо или иметь кучу лишних денег или очень ценить, чтобы в качестве целевой платформы выбирать линукс.
fshchudlo Автор
07.12.2019 22:21+1Мой комментарий про разработку, а не про конечный хостинг.
Но про перфоманс очень интересно. Можете поделиться ссылкой на сравнения? Я даже не в курсе, что с перфомансом .Net на Linux есть серьёзные проблемы.
kefirr
07.12.2019 22:53Я сравнивал — разницы по скорости в CPU-bound задачах нет. В работе с диском выигрываeт Linux. Кучу лишних денег надо иметь на лицухи для винды.
kefirr
07.12.2019 22:50+1Отвечу за себя — как и автор, перешёл на Ubuntu для разработки на .NET Core. Причины:
- Скорость. Файловая система работает быстрее, отсюда Git намного быстрее, Rider / IDEA запускаются быстрее, итд
- Другие языки и тулзы, с которыми приходится работать (docker, go, python, ..) зачастую лучше работают на линухе
- Улучшение знаний ОС, работы в терминале, etc (да, есть WSL на винде, но полное погружение способствует изучению лучше)
kefirr
07.12.2019 23:20+1Спасибо за статью! Посыл очень верный, и попробовать переехать с винды стоит каждому.
Но, говоря справедливо, не всё так гладко:
- Профайлеры. Ситуация печальная. Только сейчас в .NET Core 3.x появились инструменты от Microsoft (
dotnet-trace,dotnet-dump), да и то, результаты лучше смотреть на винде в PerfView/VS. dotTrace от JetBrains пока что только в EAP и работает не для всех версий .NET - Conference tools (Zoom, Skype, ...) — что-то работает, что-то не очень
- Нет многих других вещей типа LINQPad
- Железо — тут лотерея и танцы с бубном, особенно с ноутами и с видяхами nvidia
megasuperlexa
08.12.2019 14:42так и есть, думаю надо трезво оценивать усилия и время, затраченное на такой переход. А также пути компенсации за неизбежное снижение продуктивности.
- Профайлеры. Ситуация печальная. Только сейчас в .NET Core 3.x появились инструменты от Microsoft (
alex005
08.12.2019 00:18-1Вообще не понимаю, зачем городить свои огороды кривым забором? Есть Rancher, ставится одной командой, после установки Docker (Docker ставится тремя командами) — дальше стандартно. Вообще в последней версии Rancher v2.3.3 можно запускать кластер с рабочей нодой Windows Server Core (1909 с поддержкой контейнеров, работает, проверено) — получаешь возможность запускать .net в нативной среде (триал лицензия действует продолжительное время, потом просто в новой виртуалке генерируется новая инсталляция Eindows Server). Зачем костылить — обо всем уже давно подумали профессионально.
Varim
Уточню, если сидишь под Linux, то VirtualBox нужен ради безопасности для kubernetes?
fshchudlo Автор
Чтобы запустить kubernetes (Minikube, если быть совсем точным) желательно использовать гипервизор, иначе Minikube будет запускать свои компоненты прямо на хост-машине. Это требует установки устаревших (менее безопасных) пакетов Docker, которые сам Docker уже не рекомендует к установке.
Установка гипервизора — Virtualbox или KVM — требует добавления кастомных репозиториев, реконфигурации или вообще отключения Secure boot, возможны конфликты по версиям пакетов. Например, после установки пакета virtualbox-6.0 и последующего обновления через apt-get, я больше не смог его больше запустить из-за конфликтов версий пакетов.
В статье формулировку поправил, она действительно была непонятная, спасибо.
yleo
Нет.
Достаточно просто добавить сгенерировать и добавить свои ключи, а затем подписывать ими модули KVM или VirtualBox.
Ноже самое с версиями пакетов — "из каробки" есть репозитории для всех актуальных версий всех популярных дистрибутивов и конфликтов при этом точно не возникает.
Varim
Вы рекомендуете на девелоперскую машину устанавливать kubernetes без VirtualBox/KVM?
У вас на машине kubernetes без виртуализации?
yleo
Я предлагаю не распространять неверную информацию "требует… или вообще отключения Secure boot, возможны конфликты по версиям пакетов".
Вовсе не хочется обвинять автора, он просто неопытен и набил шишек. Но распространять такой нечаянный FUD не следует.
fshchudlo Автор
Погуглил еще — вы правы, спасибо за наводку. Статью поправил.
telpos
А если использовать гипервизор, то Minikube установит устаревшие пакеты уже в виртуальную машину?