I’ve increasingly been working with Kubernetes and hence lots of YAML files.
It’s nice and easy to get autocomplete setup for the Kubernetes YAML using this awesome extension YAML Support by Red Hat
Setup:
"yaml.schemas": {
"Kubernetes": "*.yaml"
}
Here is me setting it up and showing it off:
Massive thanks to the team that worked on the extension and language server to support this!
I’m doing some work on a golang project, the code takes a relative file path in as an argument.
Now I have Delve, VSCode and VSCode-Go installed which means I can have a nice interactive debugging session. The only snag I hit was that it wasn’t clear how to pass in my arguments when the debugger started my go code.
The trick is the use a double dash to indicate which arguments should go to the code, other args, before this, will go to the delve debugger. Also don’t forget to use “cwd” to set the working dir used when debugging.
Here is an example with comments
And we’re away…
N.B The behavior is a bit odd, as the code here suggests that the “–” should be appended for you. https://github.com/Microsoft/vscode-go/blob/master/src/debugAdapter/goDebug.ts#L306. However, this did not work for me, may be fixed in the future so double check!
Here is the scenario, I wanted to use a container to run a linux app in Azure and I need to persist changes to the filesystem via Azure Files. This, initially, appears to be nice and simple – you mount the Azure File share using CIFS and then pass this into docker as a volume mount. But what if you app relies on some linux specific operations some, like symlinks, can be emulated see here for details, but others can’t.
This is a really simple little hack which I learnt from the Azure Cloudshell implementation. It uses the ‘.img’ format to store a full EXT2 filesystem on Azure files.
How does it work? Well if you open a cloudshell instance and use the ‘mount’ command you can see it has two mounts, one for CIFS and one for a loop0.
Seeing this started to peak my interest, what was the loop0 device mounting as my home directory? The cloudshell creates a storage account to persist your files between sessions, next I took a look at this to see what I could find.
This is when I found the ‘.img’ file being used. So how do we use this approach for ourselves, as it seems to work nicely for cloudshell?
It’s actually pretty simple, we mount the Azure file share with CIFS, create the ‘.img’ file in the CIFS share, format it and then mount the ‘.img’ file. Done.
The key is to create a ‘img’ file which is sparse, meaning we don’t write all the empty space to file storage, otherwise creating a 10Gig ‘img’ file involves copying 10gig to Azure files. This is done by passing in the ‘seek’ command into dd on like 15.
So this gives you a fully compatible Linux disk stored on Azure files so it can persist container restarts and machine moves.
Ps. If you’re replicating super critical data dive this some extensive testing first, this approach worked nicely for my use case but do exercise caution.
