Девелопишь на .NET Core? Го в Ubuntu, я создал

  • Tutorial
image
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.

Only registered users can participate in poll. Log in, please.

А вы уже пробовали разработку под .NET Core на Linux?

  • 25.1%Нет, и не планирую. Винда наше все.52
  • 10.6%Пробовал, не понравилось.22
  • 26.1%Недавно попробовал, пока все здорово.54
  • 38.2%Уже давно на Linux сижу и обратно не собираюсь.79

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 39

    0
    Уточню, если сидишь под Linux, то VirtualBox нужен ради безопасности для kubernetes?
      0
      Чтобы запустить kubernetes (Minikube, если быть совсем точным) желательно использовать гипервизор, иначе Minikube будет запускать свои компоненты прямо на хост-машине. Это требует установки устаревших (менее безопасных) пакетов Docker, которые сам Docker уже не рекомендует к установке.
      Установка гипервизора — Virtualbox или KVM — требует добавления кастомных репозиториев, реконфигурации или вообще отключения Secure boot, возможны конфликты по версиям пакетов. Например, после установки пакета virtualbox-6.0 и последующего обновления через apt-get, я больше не смог его больше запустить из-за конфликтов версий пакетов.
      В статье формулировку поправил, она действительно была непонятная, спасибо.
        0
        вообще отключения Secure boot, возможны конфликты по версиям пакетов.

        Нет.


        Достаточно просто добавить сгенерировать и добавить свои ключи, а затем подписывать ими модули KVM или VirtualBox.


        Ноже самое с версиями пакетов — "из каробки" есть репозитории для всех актуальных версий всех популярных дистрибутивов и конфликтов при этом точно не возникает.

          0
          Вы рекомендуете на девелоперскую машину устанавливать kubernetes без VirtualBox/KVM?
          У вас на машине kubernetes без виртуализации?
            +3

            Я предлагаю не распространять неверную информацию "требует… или вообще отключения Secure boot, возможны конфликты по версиям пакетов".


            Вовсе не хочется обвинять автора, он просто неопытен и набил шишек. Но распространять такой нечаянный FUD не следует.

              +2
              Погуглил еще — вы правы, спасибо за наводку. Статью поправил.
          0
          А если использовать гипервизор, то Minikube установит устаревшие пакеты уже в виртуальную машину?
        +5
        Также занимаюсь разработкой под .NET в Kubuntu. Понравилось, что докер завел в полпинка в сравнении с виндой. VS Code конечно же проигрывает Visual Studio в качестве инструмента под .NET. Перешел на Rider, благо он работает под Linux, плюс быстрее, чем решарпер.
          +1
          Перешел на Rider, благо он работает под Linux, плюс быстрее, чем решарпер.

          Прошу прощения, а как вы решаете проблему лицензии? Покупаете? Или ломаете? Мне что-то совесть не даёт пользоваться ломаным продуктом. А цена на него никак не радует. Поэтому под linux'ом использую VSCode. Хотя работу в ней удобной не назовёшь. Да ещё и OmniSharp приходится периодически перезапускать, т.к. в какие-то моменты он начинает подглюкивать.
            +3

            Тоже пользуюсь Rider+Resharper на винде (Rider в первом скрипте даже записан, но закомментирован как платный), лицензионными. Только что посчитал — один рабочий день с этими инструментами стоит мне 27 рублей. Как проезд в маршрутке или пачка жвачки. Имхо, это отличная цена за получаемые комфорт и продуктивность.

              +1
              Поэтому под linux'ом использую VSCode. Хотя работу в ней удобной не назовёшь

              Странно: а по результатам недавнего опроса на StackOverflow больше половины разработчиков предпочитают именно VSCode

                +1

                В качестве альтернативы там из бесплатного только MonoDevelop, в котором для .NET Core не работает отладка. По желанию левой пятки M$FT.

                +2

                Rider себя окупит очень быстро даже для джунов (потому что научит много чему). VSCode и рядом не валялась. Не стоит экономить на рабочих инструментах.


                Плюс, полученный опыт транслируется на все остальные продукты, если придётся работать с Python, Java, Go, PHP.

                  0

                  В любом случае VSCode будет быстрее и гибче развиваться как свободный продукт + в долгосрочной перспективе лучше ориентироваться на популярные инструменты.

                    +1
                    VS Code действительно быстро развивается, но как редактор общего назначения, годный для всего подряд, неспециализированный.

                    Любая «заточка» его под конкретные нужды (тот же C#) делается через расширения. Такая модель имеет ограничения, потому что правила игры определяет сам редактор кода и они должны оставаться универсальными, подходить всем плагинам.

                    Скорее всего, мы никогда не увидим такие возможности анализа, рефакторинга, автоисправлений, контекстных действий как в Rider и в той же Visual studio. А также штуки вроде дизайнеров DbContext-ов и прочие.

                    Полагаю, что все больше функционала будет перекочевывать в консоль. В dotnet CLI уже есть шаблоны проектов, работа с зависимостями, сборка, тесты, публикация, запуск — все через консоль вместо кнопок на UI.

                    И полноценным IDE в этих условиях всегда будет место и на них будет спрос. И, скорее всего, они так и будут платными именно за свою оптимальность и продуманность для конкретных задач.
                      0
                      в долгосрочной перспективе лучше ориентироваться на популярные инструменты

                      С такой логикой можно на JavaScript или Python перейти c дотнета, они ведь популярней :)

                        0

                        Отсутствие крупного игрока, который будет поддерживать и развивать стандарты в долгосрочной перспективе, сыграло с JavaScript злую шутку. Оказалось, что даже COBOL даёт более стабильное и выгодное трудоустройство :)

                          0

                          Поделитесь статистикой про COBOL в сравнении с Javascript. По моим источникам в случае со вторым трудоустройство вполне стабильное и выгодное.

                    +1

                    Я купил лицензию. И не пожалел. Удобство в разы повышается в сравнении VsCode+OmniSharp. Встроенный клиент клиент БД по сути тот же datagrip. Мне показалось что сам Rider быстрее чем Reshaper

                  +6
                  Спасибо за статью. По-моему одного маленького шажка не хватило — Ansible. Скрипты делают своё дело, но это инструмент прошлого тысячелетия (тогда софт был заметно проще, его было меньше, open source и коллаборация были на совершенно ином уровне), поддерживать чужой плейбук проще простого, а вот скрипт уже кому как.
                    0

                    Отличная мысль, спасибо) мне как-то в голову не пришло. Попробую как с ним заведётся.

                      0
                      А это вообще про то? Вроде же нет задачи менеджерить сеть из 10+ компьютеров, а просто настроить себе рабочую машину?
                        +1
                        А Ansible и не требует 10+ хостов. Зато иногда надо рабочую машину переустановить (новое железо например).
                        Установка чего-либо скриптом не гарантирует идемпотентности, а Ansible'ом гарантирует, поэтому имеет смысл предпочесть его.
                      +1
                      Спасибо за статью, было интересно.
                        0
                        Спасибо за статью, я даже не догадывался что .NET теперь не привязана только к винде
                          +1
                          Например, без гипервизора Minikube будет запускать свои компоненты прямо на хост-машине и потребует установки устаревших пакетов Docker
                          Например, в виртуалке тоже будут устаревшие пакеты Docker?
                          Есть snap-пакет microk8s от Canonical, да и в конце концов kubeadm init хватит всем (ну ладно, ещё поставить CNI и сделать ноду рабочей, документация).
                            +3
                            а можно общий вопрос? я понимаю зачим ЗАПУСКАТЬ дотнет на линуксе, но зачем РАЗРАБАТЫВАТЬ на нём же? в чём были плюсы ухода со знакомой платформы именно для разработки-дебага?
                              +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 работать уже банально удобнее.
                                0

                                Вы сравнивали перформанс .Net приложения при запуске под Windows и Linux? С такой разницей надо или иметь кучу лишних денег или очень ценить, чтобы в качестве целевой платформы выбирать линукс.

                                  +1

                                  Мой комментарий про разработку, а не про конечный хостинг.
                                  Но про перфоманс очень интересно. Можете поделиться ссылкой на сравнения? Я даже не в курсе, что с перфомансом .Net на Linux есть серьёзные проблемы.

                                    0

                                    Я сравнивал — разницы по скорости в CPU-bound задачах нет. В работе с диском выигрываeт Linux. Кучу лишних денег надо иметь на лицухи для винды.

                                      0
                                      У меня была задачка, микросервис выбирал из базы и крутил у себя в кеше, мог выдавать запрос.
                                      Под виндой или линуксом разница в работе не ощущалась особо.
                                    +2

                                    Отвечу за себя — как и автор, перешёл на Ubuntu для разработки на .NET Core. Причины:


                                    • Скорость. Файловая система работает быстрее, отсюда Git намного быстрее, Rider / IDEA запускаются быстрее, итд
                                    • Другие языки и тулзы, с которыми приходится работать (docker, go, python, ..) зачастую лучше работают на линухе
                                    • Улучшение знаний ОС, работы в терминале, etc (да, есть WSL на винде, но полное погружение способствует изучению лучше)
                                    +4

                                    Спасибо за статью! Посыл очень верный, и попробовать переехать с винды стоит каждому.


                                    Но, говоря справедливо, не всё так гладко:


                                    • Профайлеры. Ситуация печальная. Только сейчас в .NET Core 3.x появились инструменты от Microsoft (dotnet-trace, dotnet-dump), да и то, результаты лучше смотреть на винде в PerfView/VS. dotTrace от JetBrains пока что только в EAP и работает не для всех версий .NET
                                    • Conference tools (Zoom, Skype, ...) — что-то работает, что-то не очень
                                    • Нет многих других вещей типа LINQPad
                                    • Железо — тут лотерея и танцы с бубном, особенно с ноутами и с видяхами nvidia
                                      +1
                                      так и есть, думаю надо трезво оценивать усилия и время, затраченное на такой переход. А также пути компенсации за неизбежное снижение продуктивности.
                                    • UFO just landed and posted this here
                                        0
                                        Но разве для ранчера не нужна чуть ли не 16.04 или вообще своя сборка ядро+докер? Что если мне хочется 19+ версию убунты (если честно, не уверен, зачем)?
                                        • UFO just landed and posted this here
                                            0

                                            Это радует, а то на моей последней попытке падал старт etcd ноды под 18.04 и на форуме ответили дескать так и нужно.

                                      Only users with full accounts can post comments. Log in, please.