DEV Community: NDTSTN

Running docker engine inside WSL2

NDTSTN — Thu, 01 Feb 2024 00:00:00 +0000

Running docker engine inside WSL2

Prerequisites

Windows 11 23H2 OS Build 22631.3007 How to check
UEFI / BIOS with virtualization enabled How to check

Steps:

Installing MS Store version of WSL2

Even if you’ve installed WSL2 before using one of the distributions listed in the Microsoft Store, there is a separate Store Product by Microsoft called Windows Subsystem for Linux that supports a crucial feature, called initd.

Go ahead and install that package. If you have existing distributions, they will be kept. The installation of this store product will only update WSL2 itself, and won’t mess with your distributions.

You can also install the package using WinGet within PowerShell:

winget install 9P9TQF7MRM4R --source msstore

You can check your install by running wsl --version in PowerShell or Cmd. The expected output should be similar to this:

WSL version: 2.0.14.0
Kernel version: 5.15.133.1-1
WSLg version: 1.0.59
MSRDC version: 1.2.4677
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22631.3007

Installing Ubuntu distro

Similar steps might work in other distros as well, but I have verified these steps only for the Ubuntu distro, so that’s what this tutorial will be focused on.

In powershell, run the following to install a new Ubuntu instance:

wsl --install -d Ubuntu-22.04

This command should land you in the account creation. Create your local account for the distro. After that you should be greeted with the MOTD and a bash. Go ahead and update all packages:

sudo apt-get update & sudo apt-get upgrade -y

Verify systemd

While still in bash inside the WSL2 Ubuntu instance, run:

cat /etc/wsl.conf

This should output

[boot]
systemd=true

If the file does not exist or contains something else, refer to these steps.

Install docker

Inside the Ubuntu bash, execute:

sudo bash -c 'apt-get install -y apt-transport-https ca-certificates curl software-properties-common && \
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - && \
add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" && \
apt-get update -y && apt-get install -y docker-ce && usermod -aG docker $USER && newgrp docker && exit'

Use docker

sudo docker run hello-world

Done! You can now use Docker inside your WSL2 Ubuntu 22.04!

Details & Troubleshooting

Checking Windows Version

Open the “Run” prompt of Windows by pressing Win + R
Type in “winver” into the prompt and submit the command
A window should open

Checking virtualization

Open Task Manager
Navigate to the performance “tab”
Navigate to the CPU details
The details should display “Virtualization: Enabled”

Configuring systemd inside WSL

Replace /etc/wsl.conf inside the distro with the following:

[boot]
systemd=true

In Windows, use PowerShell to power-cycle the distro:

wsl --shutdown
wsl -d Ubuntu-22.04

Green website design

NDTSTN — Sat, 19 Mar 2022 00:00:00 +0000

Green website design

In recent years, I’ve checked the carbon footprint of my personal homepage using a neat little tool available at https://websitecarbon.com.

The tool evaluates the carbon footprint of a website based on how much data it returns, and based on the type of power that is used to host the server, from what it can guess based on the IP address.

If you have a website, why don’t you give it a spin and see how you compare? :)

If you score badly, I have a couple of suggestions for you:

Framework bloat

Depending on what type of website you have, you might be subject to framework code bloating your response with no real benefit. I’ve seen blogs and personal websites with little interactivity, but shipping with full blown frontend-libraries like jQuery, Angular and React. If you are building a website that is designed only to display static information, you should look into static site generation.

If you have sites with lots of changing state and interactivity, you are of course kind of stuck with your framework. But there is still hope. Many frameworks and bundlers might have the ability to produce smaller output than what you are generating right now based on configuration.

✨ As an additional benefit, reducing framework bloat will make your page load faster. Not only on first load, but also on consecutive loads, as less scripts need to be parsed by the browser. That will make your page visitors happy, as well as increasing your SEO ratings!

Images

Images need to be optimized. While basically everyone knows this, oftentimes it’s just too much of a hassle to setup a proper image optimization pipeline or doing it manually. Use the appropriate file types for the use case. Use JPEGs for photographs and photorealistic renders, SVGs for illustrations and logos if available, and PNGs for illustrations and logos for which you don’t have vectors.

Also reduce the dimensions of your images as much as possible. You don’t want to make things blurry, but using a 4kx4k pixel image to display a tiny icon on your page is wasted data volume.

Last but not least, remove images that don’t add anything to your website. No image is better than any optimized image!

✨ As an additional benefit, your images will load more quickly, will allow for smoother scrolling which improves the visitors experience and again your SEO ratings.

HTML5

This kind of adds to the framework-bloat argument above, but you can also probably get away with using less frameworks and custom components. HTML5 is very powerful, and you don’t need a lot of CSS to make it pretty.

Instead of using large CSS libraries like bootstrap, which really only create css-class-synonyms for native css properties, just use the appropriate HTML5 tag together with some handcrafted CSS you will save lots of data volume for removing a large library, as well as simplifying your markup. Don’t forget about the cascading nature of CSS! You don’t have to repeat yourself even with plain CSS3.

✨ Using the native controls provided by your browser and not messing too much with the default layouting of elements, you will get accessibility and responsiveness mostly for free. The more you try to do something “special” with your markup and styling, the more you break the aspects of HTML5 you get for free. Stick to the semantic meaning of the HTML5 elements!

Fonts

While there are some use-cases for web fonts, like icons, you don’t need to force browsers to download 4 differently weighted versions of 3 types of fonts you might occasionally reference in your stylesheets.

You can use the system fonts. Your users will be very familiar with them. The font isn’t the place to express your uniqueness to the world!

JavaScript

If you can avoid it, do that. As an example, this entire homepage and blog runs without JavaScript. No JavaScript, no IFrames, no shenanigans. Plain and simple.

✨ Without JavaScript, your website is very robust. It can’t really fail to do anything, because it doesn’t do anything.

Tracking and ads

I don’t think I need to say anything here.

✨ Bonus: No ads and no tracking means less/no cookies, easier/no banners and easier/no privacy policy of.

✨ Bonus 2: If you are in Germany, don’t do commerce and don’t collect user data, you won’t need to provide an imprint for your personal homepage :)

I have a dream about dynamic environment provisioning

NDTSTN — Fri, 16 Oct 2020 00:00:00 +0000

I have a dream about dynamic environment provisioning

The repeating annoyance of pre-release madness

Oftentimes when developing larger business applications in a larger team, you run into problems as you get close to release dates. You and your colleages finally merge all of their changes together, it deploys to a test environment and something breaks. Assuming you’ve all had a couple of bug fixes at the end of the sprint, and with larger features just completing in time to be included for the release, you are all left with a broken application the evening before release. What to do?

You revert changes, deploy again and try again, as long as it’s still broken. Numerous deployments to testing reveal, that one of the many PRs broke the app. But it’s not obvious why. Somebody probably f_cked up a merge conflict. Everything is merged together again, a couple other problems arise in the meantime, but in the end, you scuff together a presentable version for next days sprint review and deployment.

While it did work out in the end, and everybody was working together as a team to solve this challenge (funnily enough, it’s a bonding experience that will be remembered), I think it comes with a lot of unnecessary pain.

A good portion of the solution revolved around chopping up the changes into smaller pieces again and to test intermediate revisions of the result. Deploying these one after the other and testing these sequentially, wastes a lot of time. A lot of the time is spent waiting for CI/CD pipelines.

Make annoyance go bleh

I’d like to propose a different solution. Be prepared for such incidents by having the ability to easily create additional environments. Don’t limit your testing by environments. Each PR could spin up an environment. This could be be helpful to prevent a lot of issues. Testers could be part of the PR review group testing specific PR changes.

This is even helpful for developers, as you can now also quickly look at what the code is actually changing. You get to see the result. Not just the source. Which can improve quality in many ways. Oftentimes developers become blind to obvious design problems on web pages for example. Having the resulting page visible as part of the PR would allow for “fast failing” in those areas.

If well integrated, automated E2E tests could be executed on those environments. The flexibility gained by such a setup is really convenient. It’s also helping to increase confidence in your solution. The ability to easily just create an instance isolated from other environments would definitely help me sleep better.

It forces the team to invest thoughts into provisioning, deploying and seeding environments, which are aspects of development that easily fall out of focus when time is running out in a sprint. Schema migrations, seeding and similar issues are often at fault for final release day madness and embarrassed team members.

Caveats

Of course this will be a bit more expensive on your infrastructure resources. You have to make sure to unprovision all these environments, as soon as they are no longer required. Though that shouldn’t be that big of a deal, as accidentally removing one too many isn’t a problem, as it can be recreated easily.

This also only really works, when you are able to isolate the application from other systems you don’t have control over / can’t provision automatically.

Make sure not to forget continuous environments. It’s great if you can spin up different environments quickly, but that doesn’t help, if after every release you need to recreate production because the data isn’t compatible. I assume it’s necessary to still have permanent environments for testing too, to make sure that your previous release version is updatable to your new version with all it’s “legacy” data.

Speaking of legacy data, don’t forget to hydrate data storages with reasonable amounts of data comparable to production systems proportional to the machine sizes you use. If your API works great with 10 users and falls apart at 100, you can’t really release that to a production environment with 400.000 users. This applies to all non-production environments though, even permanent ones, as they often don’t accumulate as much data as production environments. So strictly speaking it’s not a caveat of dynamic provisioning, but more a caveat of “not changing code directly in production” which itself comes with a bunch of other more severe caveats IMO.

Discussion

Do you have experience with this stuff? How would you go about implementing this kind of integration and isolation? Are there industry solutions out there doing this? Let me know by shooting me an issue onGitHub.

I have a dream about conventional commits

NDTSTN — Thu, 08 Oct 2020 00:00:00 +0000

I have a dream about conventional commits

Everyone these days has heard of semver, as most package managers try to enforce it upon their packages.

While the idea behind it is nobel, the execution often lacks.

We’ve all been screwed by some form of sentimental versioningbefore I’m sure, so here’s an idea you might not have heard of:

Conventional Commits

Use ✨conventional commits✨, introduce some tooling, and you’ll be semantically versioning in no time.

Commit messages are subject to rules according to a specification which ensures, that the git history can be tracked for patch, minor and major changes.

As a bonus, you can from now on generate your CHANGELOG.md as well.

Thanks for adhering to my advice.

Discussion

Are you already comitting conventionally? How is it working out for you? Was it hard to adapt with an entire team?

Let me know by submitting an issue on GitHub.

I have a dream(rant) about secrets in repositories

NDTSTN — Tue, 18 Aug 2020 00:00:00 +0000

I have a dream rant about secrets in repositories

TL DR: Please don’t put them there

What?

I’ve been working in the software development business professionally for 5 years now. The company I work for has yet to “discover” open source. We heavily use OSS, but have nothing up of our own stuff. That may be the reason why nobody so far has ever questioned putting secrets into git repositories.

That would be one of the first lessons, when pushing anything into a public repository. No secrets. It’s that simple.

Why not?

For public repositories, I think it should be fairly obvious, that putting secrets there is a bad idea.

But even for private repos, there is always a chance of leaking the repo. A quick clone on some machine. Drive may not be encrypted and the device gets lost. Of course you forget, which repos have been cloned to that machine. Nobody keeps track of that. I have probably 30 something repos on my dev machine. Some of which containing secrets that can potentially cause damage.

appsettings.json => connection strings => sql db => drop

Or even worse, silently taking dumps and blackmailing us. The problem wouldn’t be as bad, when secrets would rotate often. But sadly, that’s another problem we haven’t touched. It’s been getting better lately, but there’s still room for improvement.

Another problem is versioning. It might not come off as a huge problem, but the commit history is cluttered with our devops people commiting “config” over and over again, as they want to trigger our continuous deployment with different settings in a trial and error manner. It’s a cool setup. We have branches for each environment, and you just have to merge into them, and as they update, they will be deployed. It’s cool as long as you go “forward”. If you want to get back to a different version, or want to try a feature branch on some environment, you will be faced with reverting commits, which is kinf of stupid, because then you’d have to revert the revert, if you were to ever test that branch again. Resetting the branch would be better, but often people will branch off of these CD branches, so their branch will be infected with these broken config changes that way.

Also, any intern starting to set foot in one of the real projects requiring access to code, will automatically be granted access to all of the environments secrets. Good stuff.

A vision for improvement

So what’s my dream solution about?

Don’t put secrets into the repository. Treat every repository, as if it was public.

What about that cool CI/CD pipeline we have going on? Well, we can keep it. We just have to make some changes to it.

Have two build pipelines: Debug & Release

They are analogous to the build definitions Debug and Release.

Define your secrets in your Release pipelines. Have a release pipeline for every environment.

Now you can use any build, and deploy it to any environment. No more config changes are tracked in the repo. Having a hard to repro bug in production? Just deploy the Debug version there for some extra verbose error tracking for a couple minutes.

Want to test a feature branch? Select your preferred build definition. Select an environment, done.

As a bonus, you also have increased confidence, that moving a code version from one environment to another won’t introduce additional changes, that may have happened in the target environment branch before.

Of course you still need to communicate about who is putting what into which environment. Unless you can dynamically provision new environments, but that’s a dream for another night.

But what if the config schema changes?

That would break the pipelines, and that’s good?

It’s a great way to interpret semver for code, that nobody depends on. If you develop a product with no exposed APIs, it’s a bit difficult to define what change would be breaking and therefor a major version increase. But the configuration schema is kind of like an interface, that the application needs to support.

Whenever the config schema changes, or existing configs in your pipelines will break, that’s a major code version increase for your repository.

Now your repository is managing code only. Your commits can now focus on development. No more “config”. You don’t have builds that only work for one environment. You don’t need to rebuild to move a code version from one environment to another. You just deploy the same code with different config to the next environment.

Code => Build

Build + Config => Release

And the intern can finally work on all them cool projects without seeing prod credentials.

A great time to be alive.

Who is responsible for this mess?

Microsoft.

All the samples and project templates are generating configuration files ready for committing them. The default VS .gitignore won’t ignore appsettings.json and similar files.

Discussion

Are you already living the dream? Are there problems I haven’t thought about? Shoot me an issue on GitHub.

Advanced Dependency Injection in .NET Core

NDTSTN — Wed, 20 May 2020 18:03:22 +0000

Hi,

inspired by this years Microsoft Build conference I decided to get back to creating my own videos about things all around the .NET ecosystem.

This morning I took a stab at explaining the .NET Core dependency injection extension, from basics to how other frameworks utilize it internally, like ASP.NET Core.

It is not 100% beginner friendly, as I won't explain DI in itself. I just detail how this specific implementation of an IoC container works.

Here it is:

Fallback link: https://youtu.be/VwIRrsQDVWQ

I also plan on doing more videos, so please give me some feedback for improving the videos. You can also request topics that I should cover.

Happy coding everyone
~InDieTasten