<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Posts on Tux-Sudo</title><link>https://blog.tux-sudo.com/posts/</link><description>Recent content in Posts on Tux-Sudo</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sun, 16 Aug 2020 15:02:39 +0530</lastBuildDate><atom:link href="https://blog.tux-sudo.com/posts/index.xml" rel="self" type="application/rss+xml"/><item><title>Production Grade Web Services with Go - Tying it Together</title><link>https://blog.tux-sudo.com/posts/production-grade-svc-4/</link><pubDate>Sun, 16 Aug 2020 15:02:39 +0530</pubDate><guid>https://blog.tux-sudo.com/posts/production-grade-svc-4/</guid><description>&lt;p&gt;Note : This is part four of a series of posts describing how to write &amp;ldquo;Production Grade Webservices in Go&amp;rdquo;. Here&amp;rsquo;s &lt;a href="https://blog.tux-sudo.com/posts/production-grade-svc-1/"&gt;Part - 1, The Service &lt;/a&gt;, &lt;a href="https://blog.tux-sudo.com/posts/production-grade-svc-2/"&gt;Part - 2, The Store &lt;/a&gt;, &lt;a href="https://blog.tux-sudo.com/posts/production-grade-svc-3"&gt;Part - 3, Transports&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;In part-3, we built a working HTTP service that passed the tests. But we&amp;rsquo;re still lacking the option to actually &amp;ldquo;run&amp;rdquo; it. While, this may appear like a trivial task, it&amp;rsquo;s actually quite important to get this right.
Something I feel rather strongly about is the need to avoid package level variables and global state in Go programs. Like plenty of other things, Peter Bourgon says it perfectly in &lt;a href="https://peter.bourgon.org/blog/2017/06/09/theory-of-modern-go.html"&gt;this post&lt;/a&gt;:&lt;/p&gt;</description></item><item><title>Production Grade Web Services with Go - Transports</title><link>https://blog.tux-sudo.com/posts/production-grade-svc-3/</link><pubDate>Sat, 04 Jul 2020 15:30:44 +0530</pubDate><guid>https://blog.tux-sudo.com/posts/production-grade-svc-3/</guid><description>&lt;p&gt;Note : This is part three of a series of posts describing how to write &amp;ldquo;Production Grade Webservices in Go&amp;rdquo;. Here&amp;rsquo;s &lt;a href="https://blog.tux-sudo.com/posts/production-grade-svc-1/"&gt;Part - 1, The Service &lt;/a&gt; and &lt;a href="https://blog.tux-sudo.com/posts/production-grade-svc-2"&gt;Part - 2 The Store &lt;/a&gt; if you haven&amp;rsquo;t read those.&lt;/p&gt;
&lt;p&gt;We&amp;rsquo;ve reached a point where we have properly laid out the business logic and the storage implementation for our service. Now, we&amp;rsquo;re going to move on and talk about &lt;strong&gt;transports&lt;/strong&gt;. As the name suggests, a transport is essentially transporting data over the network in a pre-defined format. JSON over HTTP is one such transport. gRPC is another. We&amp;rsquo;re going to start with JSON over HTTP simply because of how popular it is. I may write a separate post that adds a gRPC transport to this very service later, but for now, HTTP-JSON.&lt;/p&gt;</description></item><item><title>Production Grade Web Services with Go - The Store</title><link>https://blog.tux-sudo.com/posts/production-grade-svc-2/</link><pubDate>Mon, 08 Jun 2020 12:16:15 +0530</pubDate><guid>https://blog.tux-sudo.com/posts/production-grade-svc-2/</guid><description>&lt;p&gt;Note : This is part two of a series of posts describing how to write &amp;ldquo;Production Grade Webservice in Go&amp;rdquo;. Here&amp;rsquo;s &lt;a href="https://blog.tux-sudo.com/posts/production-grade-svc-1/"&gt;Part - 1, The Service &lt;/a&gt; if you haven&amp;rsquo;t read it.&lt;/p&gt;
&lt;p&gt;The previous post ended with a defined structured for our service and some basic testing. It was, however, lacking what is a very important component for most webservices, a &lt;strong&gt;datastore&lt;/strong&gt;. If you&amp;rsquo;ve used frameworks to write services in the past, you&amp;rsquo;re probably familiar with abstractions like Hibernate/DjangoORM etc. While Go has the option of working with similar alternatives (&lt;a href="https://gorm.io/"&gt;GORM&lt;/a&gt;, &lt;a href="https://github.com/gobuffalo/pop"&gt;Pop&lt;/a&gt;), I generally find building a simple custom abstraction over the database to be better. Unless you have a lot CRUD like APIs with plenty of models, direct is, in my opinion, better. See this &lt;a href="https://eli.thegreenplace.net/2019/to-orm-or-not-to-orm/"&gt;post&lt;/a&gt; for more information.&lt;/p&gt;</description></item><item><title>Production Grade Web Services with Go - The Service</title><link>https://blog.tux-sudo.com/posts/production-grade-svc-1/</link><pubDate>Sun, 07 Jun 2020 09:33:15 +0000</pubDate><guid>https://blog.tux-sudo.com/posts/production-grade-svc-1/</guid><description>&lt;p&gt;Production Grade is a term thrown around a lot these days. Every organization seems to have it&amp;rsquo;s own definition for what qualifies as &amp;ldquo;Production Grade&amp;rdquo; or &amp;ldquo;Production Ready&amp;rdquo;. In these series of posts, I&amp;rsquo;m going to present my take on the topic and the bare minimum of what I think qualifies under this definition. These posts assume a working knowledge of Go and are not meant for total beginners to the language.&lt;/p&gt;</description></item><item><title>Azure SDK Go</title><link>https://blog.tux-sudo.com/posts/azure-sdk-go/</link><pubDate>Mon, 18 May 2020 11:06:04 +0000</pubDate><guid>https://blog.tux-sudo.com/posts/azure-sdk-go/</guid><description>&lt;p&gt;So, I&amp;rsquo;ve recently had to work with the &lt;a href="https://github.com/Azure/azure-sdk-for-go"&gt;Azure-SDK&lt;/a&gt; for a few small tasks. I&amp;rsquo;ve worked with AWS and GCP SDKs before, and while they have their problems it wasn&amp;rsquo;t too hard to figure them out. Azure wasn&amp;rsquo;t quite the same.&lt;/p&gt;
&lt;p&gt;Now, I am new to Azure, but I did not expect to spend 30 minutes to get a simple VM listing to work. The &lt;a href="https://github.com/Azure/azure-sdk-for-go#authentication"&gt;Authentication&lt;/a&gt; docs seemed fairly straight forward. I just need my credentials now. Okay, google, tell me how to do that. I read the official docs and they did not seem very easy to navigate. Eventually, I figured it out. Here&amp;rsquo;s the gist of it for anyone still wondering:&lt;/p&gt;</description></item><item><title>Easy SSL Termination - CORS Edition</title><link>https://blog.tux-sudo.com/posts/caddy-reverse-proxy-ssl-cors/</link><pubDate>Tue, 05 May 2020 09:43:52 +0000</pubDate><guid>https://blog.tux-sudo.com/posts/caddy-reverse-proxy-ssl-cors/</guid><description>&lt;p&gt;I&amp;rsquo;ve always been a big fan of &lt;a href="https://caddyserver.com/"&gt;Caddy&lt;/a&gt;, and it just got a 2.0 release! In the meantime, I have developed another throwaway service called &lt;a href="https://github.com/tchaudhry91/archy"&gt;Archy&lt;/a&gt;, and naturally, it deserves the best Ops can offer.&lt;/p&gt;
&lt;p&gt;So, here&amp;rsquo;s the scenario. I need a simple HTTPS service exposed to the world. I have a VPS with a public IP. Of course, I&amp;rsquo;ll celebrate Caddy&amp;rsquo;s 2nd birth and write a simple Caddyfile.&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre tabindex="0" class="chroma"&gt;&lt;code class="language-bash" data-lang="bash"&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;archy.tux-sudo.com
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;reverse_proxy /* 127.0.0.1:15999
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;Done. Cool. See you later.&lt;/p&gt;</description></item><item><title>Go: Useful Development Workflows</title><link>https://blog.tux-sudo.com/posts/golang-github-actions/</link><pubDate>Mon, 23 Dec 2019 05:32:57 +0000</pubDate><guid>https://blog.tux-sudo.com/posts/golang-github-actions/</guid><description>&lt;p&gt;Code Coverage, Static Code Analysis, Tests, Releases? What else? Probably a few more things, but you get the point. These are all things that are expected to be part of a modern day development workflow. While this is becoming the norm in companies, a lot of pet open-source projects still skimp on these things. And frankly, I did too. I wasn&amp;rsquo;t going to bother hosting my own Jenkins behemoth just so my soon-to-be abandoned project could run a few builds. But with practically everything available as a SaaS (and in most cases, free for open source projects), I had no excuse anymore.
Travis/Circle/GitlabCI/AzurePipelines etc. were already quite common and with GitHub&amp;rsquo;s entry into the fray, there really is no reason not to have atleast a simple CI workflow on your project.&lt;/p&gt;</description></item><item><title>Go: Spin-Up Databases for CI Testing</title><link>https://blog.tux-sudo.com/posts/ci-docker-dbs/</link><pubDate>Fri, 20 Sep 2019 06:19:22 +0000</pubDate><guid>https://blog.tux-sudo.com/posts/ci-docker-dbs/</guid><description>&lt;p&gt;One thing has always bothered me while writing tests is the lack of a real datasource to run tests against. Most projects I&amp;rsquo;ve worked with in the past have either mocked responses from a datastore or used a &amp;ldquo;common&amp;rdquo; datastore to perform tests against. While mocks are good for quick unit tests, I still prefer using a &amp;ldquo;real&amp;rdquo; datasource, especially for integration tests.&lt;/p&gt;
&lt;p&gt;While taking Bill Kennedy&amp;rsquo;s Ultimate Go training a while ago, I saw Bill recommend a testing approach which involved &amp;ldquo;spinning up&amp;rdquo; a database container right from within your test code, run your tests, and clean-up. See &lt;a href="https://github.com/ardanlabs/service/blob/master/internal/platform/database/databasetest/docker.go"&gt;this&lt;/a&gt; for reference. I love this approach. It provides a wonderful way to do everything from within &lt;code&gt;go test&lt;/code&gt; without meddling with external scripts, thereby providing much greater interoperability. My only gripe with this is the fact that it uses &lt;code&gt;os.exec&lt;/code&gt; to command communicate with the docker daemon. The approach is sound, however, I find forking out to use docker-cli to be a bit clunky. Docker&amp;rsquo;s client for go is pretty good and offers imho, a better way to achieve the same. It adds a dependency to the code, however, I believe that is a good thing. The real dependency here is the daemon on the underlying system. Taking a dependency in Go code, makes the management of the API easier and offers more control than relying on the cli api silently. Moreover, if you only use the dependency in your &lt;code&gt;_test.go&lt;/code&gt; files, it won&amp;rsquo;t impact the final build binary (or that&amp;rsquo;s my understanding atleast, someone correct me if I&amp;rsquo;m wrong). In most cases the exec approach is perhaps good enough and the right thing to do, but I have an alternative.&lt;/p&gt;</description></item><item><title>ARM Your Golang Containers</title><link>https://blog.tux-sudo.com/posts/armyourcontainers/</link><pubDate>Mon, 19 Mar 2018 11:52:57 +0530</pubDate><guid>https://blog.tux-sudo.com/posts/armyourcontainers/</guid><description>&lt;p&gt;So then, here is the deal. I write tiny microservices that may or may not serve any purpose. Despite how meaningless they might be, I give them the perfect operations treatment.&lt;/p&gt;</description></item><item><title>Caddy! Team 443 FTW</title><link>https://blog.tux-sudo.com/posts/caddy-autohttps/</link><pubDate>Mon, 19 Feb 2018 11:01:54 +0530</pubDate><guid>https://blog.tux-sudo.com/posts/caddy-autohttps/</guid><description>&lt;p&gt;This one is a gamechanger. It really is.&lt;/p&gt;
&lt;p&gt;On a recent Golang obsessed Github browsing spree, I read the following project description: &amp;ldquo;Fast, cross-platform HTTP/2 web server with automatic HTTPS&amp;rdquo;. I&amp;rsquo;ve read that before, and more often than not ended up disappointing myself and resorting to hacks like [this] (&lt;a href="https://blog.tux-sudo.com/posts/letsencrypt-nginx-docker/"&gt;https://blog.tux-sudo.com/posts/letsencrypt-nginx-docker/&lt;/a&gt;) to create an automatic TLS system for my websites. There are other ways, but almost all of them were semi-automatic in the long run (yay cron!). I decided to try out [Caddy] (&lt;a href="https://caddyserver.com/)"&gt;https://caddyserver.com/)&lt;/a&gt;.&lt;/p&gt;</description></item><item><title>LetsEncrypt Certificates for Dockerized Nginx</title><link>https://blog.tux-sudo.com/posts/letsencrypt-nginx-docker/</link><pubDate>Tue, 26 Sep 2017 16:25:49 +0530</pubDate><guid>https://blog.tux-sudo.com/posts/letsencrypt-nginx-docker/</guid><description>&lt;p&gt;I like nginx. I like docker. I like SSL. I also like not paying for SSL certificates.&lt;br&gt;
If you, like me are operating a small time website, you probably don&amp;rsquo;t want to dish out a few hundred dollars for an SSL certificate.Thankfully, &lt;a href="https://letsencrypt.org"&gt;LetsEncrypt&lt;/a&gt; provides &lt;strong&gt;free&lt;/strong&gt; ssl certificates and is now trusted by most major browsers.&lt;br&gt;
However, integrating &lt;a href="https://certbot.eff.org/"&gt;certbot&lt;/a&gt; to automatically configure my nginx inside a docker container has been a pain. In the past, I generated the standalone cert with &amp;ndash;cert-only and then linked my docker container to use it but this was a far from usable solution given the horrid automation code I had to write. &lt;br&gt;
Recently, I tried to come up with a more automation friendly solution and ended up with the following:&lt;br&gt;&lt;/p&gt;</description></item></channel></rss>