<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Muhammed Karamuk - Software Developer - Personal Blog</title><link>https://www.mkaramuk.dev/</link><description>Recent content on Muhammed Karamuk - Software Developer - Personal Blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 09 Jul 2024 00:00:00 +0000</lastBuildDate><atom:link href="https://www.mkaramuk.dev/index.xml" rel="self" type="application/rss+xml"/><item><title>Creating Container Image Registry</title><link>https://www.mkaramuk.dev/posts/creating-container-image-registry/</link><pubDate>Tue, 09 Jul 2024 00:00:00 +0000</pubDate><guid>https://www.mkaramuk.dev/posts/creating-container-image-registry/</guid><description>&lt;p&gt;Hi there,&lt;/p&gt;
&lt;p&gt;Sometimes you may need to create your own container image registry, either running on your local machine or on cloud/on-prem, where you manage it by yourself. Examples for use cases:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;The images owned by your organization are high in size and take longer to upload to remote locations,&lt;/li&gt;
&lt;li&gt;Access control over the images,&lt;/li&gt;
&lt;li&gt;Image encryption,&lt;/li&gt;
&lt;li&gt;Requirement to upload images to remote registry during the development process,&lt;/li&gt;
&lt;/ul&gt;
&lt;h1 id="what-is-container-image-registry"&gt;What is Container Image Registry?&lt;/h1&gt;
&lt;p&gt;Container images basically exists in two places; your local machine and remote image registries.&lt;/p&gt;</description></item><item><title>dotenvx - New generation dotenv tool</title><link>https://www.mkaramuk.dev/posts/dotenvx-new-generation-dotenv-tool/</link><pubDate>Wed, 03 Jul 2024 00:00:00 +0000</pubDate><guid>https://www.mkaramuk.dev/posts/dotenvx-new-generation-dotenv-tool/</guid><description>&lt;p&gt;Hello there,&lt;/p&gt;
&lt;p&gt;In this article, we will take a look at &lt;a href="https://dotenvx.com/"&gt;dotenvx&lt;/a&gt; which is created by the developer behind &lt;a href="https://github.com/motdotla/dotenv"&gt;dotenv&lt;/a&gt;, &lt;a href="https://github.com/motdotla"&gt;@motdotla&lt;/a&gt;.&lt;/p&gt;
&lt;h2 id="what-was-dotenv"&gt;What was dotenv?&lt;/h2&gt;
&lt;p&gt;As you all know, we configure the programs we write to use environment variables to determine how they should work. To avoid having to redefine these environment variables every time we run the program, we use &lt;em&gt;.env&lt;/em&gt; files.&lt;/p&gt;
&lt;p&gt;Basically, the logic behind of the &lt;em&gt;.env&lt;/em&gt; files is very simple; read the &lt;em&gt;.env&lt;/em&gt; file on the path (by default in the process working directory) and make the variables defined in it available to our program as environment variables. This way, when we want to run our program, we don&amp;rsquo;t have to define the variables we need one by one.&lt;/p&gt;</description></item></channel></rss>