<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Service Account on dobriak::blog</title>
    <link>https://dobriak.github.io/tags/service-account/</link>
    <description>Recent content in Service Account on dobriak::blog</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 30 Apr 2018 09:39:03 -0700</lastBuildDate>
    
	<atom:link href="https://dobriak.github.io/tags/service-account/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>Autoscaling Reporter</title>
      <link>https://dobriak.github.io/post/autoscaling-reporter/</link>
      <pubDate>Mon, 30 Apr 2018 09:39:03 -0700</pubDate>
      
      <guid>https://dobriak.github.io/post/autoscaling-reporter/</guid>
      <description>&lt;p&gt;I frequently get asked about utilizing AWS CloudWatch metrics collecting abilities to autoscale DC/OS EE clusters. Usually people figure out quickly how to use the AWS built in metrics (for example CPU utilization) but are not completely sure how they can start emitting their own, custom ones and use those instead.&lt;/p&gt;

&lt;p&gt;In this article, I will help you set up a simple Marathon app that will do just that for us: forward some DC/OS built-in metrics and even create and push a custom one.&lt;/p&gt;

&lt;p&gt;&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>DC/OS Service Accounts in Restricted Environments</title>
      <link>https://dobriak.github.io/post/service-account-restricted-environment/</link>
      <pubDate>Sun, 29 Apr 2018 15:44:45 -0700</pubDate>
      
      <guid>https://dobriak.github.io/post/service-account-restricted-environment/</guid>
      <description>&lt;p&gt;We are so used to having handy little pieces of software that help us do our jobs better. If you too work in the DevOps world and write automation for infrastructure or software (or pretty much anything else) you know what I mean. Take &lt;code&gt;jq&lt;/code&gt; for an example: can you imagine writing any sort of shell script that interacts with any JSON producing API and &lt;em&gt;NOT&lt;/em&gt; using good ole trustworthy &lt;code&gt;jq&lt;/code&gt;?&lt;/p&gt;

&lt;p&gt;&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Secure Kafka Install on DC/OS</title>
      <link>https://dobriak.github.io/post/secure-kafka-install/</link>
      <pubDate>Sat, 27 Jan 2018 12:34:45 -0700</pubDate>
      
      <guid>https://dobriak.github.io/post/secure-kafka-install/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;https://kafka.apache.org/&#34;&gt;Apache Kafka&lt;/a&gt; is a distributed high-throughput publish-subscribe messaging system with strong ordering guarantees. Kafka clusters are highly available, fault tolerant, and very durable. DC/OS offers a &lt;a href=&#34;https://github.com/dcos/examples/tree/master/kafka/1.10&#34;&gt;single click install&lt;/a&gt; of Kafka as a framework which is great for trying out. When it comes to actually using it in a Dev/Test/Production environment, you should definitely consider securing your Kafka installation. You will be required to do so if you are running your DC/OS EE cluster in &lt;code&gt;strict&lt;/code&gt; mode.&lt;/p&gt;</description>
    </item>
    
  </channel>
</rss>