<?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>Ops on Tux-Sudo</title><link>https://blog.tux-sudo.com/categories/ops/</link><description>Recent content in Ops on Tux-Sudo</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 05 May 2020 09:43:52 +0000</lastBuildDate><atom:link href="https://blog.tux-sudo.com/categories/ops/index.xml" rel="self" type="application/rss+xml"/><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>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>