A long time ago in a galaxy far, far away (OK, so it was 2008 and it was here in this galaxy—on this very planet, in fact), I posted an article about bringing your spouse to VMworld. That one post sparked a fire that, kindled by my wife’s passion and creativity, culminates this year in ten years of Spousetivities! Yes, Spousetivities is back at VMworld (both US and Europe) this year, and Crystal has some pretty nice events planned for this year’s participants.
Registration is here, and here’s a quick look at some of the activities planned for VMworld US in Las Vegas:
A long time ago in a galaxy far, far away (OK, so it was 2008 and it was here in this galaxy—on this very planet, in fact), I posted an article about bringing your spouse to VMworld. That one post sparked a fire that, kindled by my wife’s passion and creativity, culminates this year in ten years of Spousetivities! Yes, Spousetivities is back at VMworld (both US and Europe) this year, and Crystal has some pretty nice events planned for this year’s participants.
Registration is here, and here’s a quick look at some of the activities planned for VMworld US in Las Vegas:
A long time ago in a galaxy far, far away (OK, so it was 2008 and it was here in this galaxy—on this very planet, in fact), I posted an article about bringing your spouse to VMworld. That one post sparked a fire that, kindled by my wife’s passion and creativity, culminates this year in ten years of Spousetivities! Yes, Spousetivities is back at VMworld (both US and Europe) this year, and Crystal has some pretty nice events planned for this year’s participants.
Registration is here, and here’s a quick look at some of the activities planned for VMworld US in Las Vegas:
I’m now roughly six months into using Linux as my primary laptop OS, and it’s been a few months since my last progress report. If you’re just now picking up this thread, I encourage you to go back and read my initial progress report, see which Linux distribution I selected, or check how I chose to handle corporate collaboration (see here, here, and here). In this post, I’ll share where things currently stand.
My configuration is unchanged from the last progress report. I’m still running Fedora 25, and may consider upgrading to Fedora 26 when it releases (due to be released tomorrow, I believe). I’m still using the Dell Latitude E7370, which continues—from a hardware perspective—to perform admirably. CPU power is a bit limited, but that’s to be expected from a mobile-focused chip. My line-up of applications also remains largely unchanged as well.
Some things are working really well:
I’m now roughly six months into using Linux as my primary laptop OS, and it’s been a few months since my last progress report. If you’re just now picking up this thread, I encourage you to go back and read my initial progress report, see which Linux distribution I selected, or check how I chose to handle corporate collaboration (see here, here, and here). In this post, I’ll share where things currently stand.
My configuration is unchanged from the last progress report. I’m still running Fedora 25, and may consider upgrading to Fedora 26 when it releases (due to be released tomorrow, I believe). I’m still using the Dell Latitude E7370, which continues—from a hardware perspective—to perform admirably. CPU power is a bit limited, but that’s to be expected from a mobile-focused chip. My line-up of applications also remains largely unchanged as well.
Some things are working really well:
I’m now roughly six months into using Linux as my primary laptop OS, and it’s been a few months since my last progress report. If you’re just now picking up this thread, I encourage you to go back and read my initial progress report, see which Linux distribution I selected, or check how I chose to handle corporate collaboration (see here, here, and here). In this post, I’ll share where things currently stand.
My configuration is unchanged from the last progress report. I’m still running Fedora 25, and may consider upgrading to Fedora 26 when it releases (due to be released tomorrow, I believe). I’m still using the Dell Latitude E7370, which continues—from a hardware perspective—to perform admirably. CPU power is a bit limited, but that’s to be expected from a mobile-focused chip. My line-up of applications also remains largely unchanged as well.
Some things are working really well:
Welcome to Technology Short Take #84! This episode is a bit late (sorry about that!), but I figured better late than never, right? OK, bring on the links!
Welcome to Technology Short Take #84! This episode is a bit late (sorry about that!), but I figured better late than never, right? OK, bring on the links!
Welcome to Technology Short Take #84! This episode is a bit late (sorry about that!), but I figured better late than never, right? OK, bring on the links!
Back in early March of this year, I wrote a post on customizing the Docker Engine on CentOS Atomic Host. In that post, I showed how you could use systemd constructs like drop-in units to customize the behavior of the Docker Engine when running on CentOS Atomic Host. In this post, I’m going to build on that information to show how this can be done using cloud-init on a public cloud provider (AWS, in this case).
Although I haven’t really blogged about it, I’d already taken the information in that first post and written some Ansible playbooks to do the same thing (see here for more information). Thus, one could use Ansible to do this when running CentOS Atomic Host on a public cloud provider. However, much like the original post, I wanted to find a very “cloud-native” way of doing this, and cloud-init seemed like a pretty good candidate.
All in all, it was pretty straightforward—with one significant exception. As I was testing this, I ran into an issue where the Docker daemon wouldn’t start after cloud-init had finished. Convinced I’d done something wrong, I kept going over the files, testing and re-testing (I’ve been working on this, off Continue reading
Back in early March of this year, I wrote a post on customizing the Docker Engine on CentOS Atomic Host. In that post, I showed how you could use systemd constructs like drop-in units to customize the behavior of the Docker Engine when running on CentOS Atomic Host. In this post, I’m going to build on that information to show how this can be done using cloud-init on a public cloud provider (AWS, in this case).
Although I haven’t really blogged about it, I’d already taken the information in that first post and written some Ansible playbooks to do the same thing (see here for more information). Thus, one could use Ansible to do this when running CentOS Atomic Host on a public cloud provider. However, much like the original post, I wanted to find a very “cloud-native” way of doing this, and cloud-init seemed like a pretty good candidate.
All in all, it was pretty straightforward—with one significant exception. As I was testing this, I ran into an issue where the Docker daemon wouldn’t start after cloud-init had finished. Convinced I’d done something wrong, I kept going over the files, testing and re-testing (I’ve been working on this, off Continue reading
Back in early March of this year, I wrote a post on customizing the Docker Engine on CentOS Atomic Host. In that post, I showed how you could use systemd constructs like drop-in units to customize the behavior of the Docker Engine when running on CentOS Atomic Host. In this post, I’m going to build on that information to show how this can be done using cloud-init on a public cloud provider (AWS, in this case).
Although I haven’t really blogged about it, I’d already taken the information in that first post and written some Ansible playbooks to do the same thing (see here for more information). Thus, one could use Ansible to do this when running CentOS Atomic Host on a public cloud provider. However, much like the original post, I wanted to find a very “cloud-native” way of doing this, and cloud-init seemed like a pretty good candidate.
All in all, it was pretty straightforward—with one significant exception. As I was testing this, I ran into an issue where the Docker daemon wouldn’t start after cloud-init had finished. Convinced I’d done something wrong, I kept going over the files, testing and re-testing (I’ve been working on this, off Continue reading
Welcome to Technology Short Take #83! This is a slightly shorter TST than usual, which might be a nice break from the typical information overload. In any case, enjoy!
ssh-copy-id on servers, but for network devices (leveraging Netmiko). Check out the GitHub repository.The idea of an SSH bastion host is something I discussed here about 18 months ago. For the most part, it’s a pretty simple concept (yes, things can get quite complex in some situations, but I think these are largely corner cases). For the last few months, though, I’ve been trying to use an SSH bastion host and failing, and I could not figure out why it wouldn’t work. The answer, it turns out, lies in custom SSH configurations.
In my introduction on using SSH bastion hosts (linked above)—or in just about any tutorial out there on using SSH bastion hosts—brief mention is made of adding configuration information to SSH to use the bastion host. Borrowing from my original post, if you had an instance named “private1” that you wanted to access via a bastion named “bastion”, the SSH configuration information might look like this:
Host private1
IdentityFile ~/.ssh/rsa_private_key
ProxyCommand ssh user@bastion -W %h:%p
Host bastion
IdentityFile ~/.ssh/rsa_private_key
Normally, that information would go into ~/.ssh/config, which is the default SSH configuration file.
In my case, I only allow public key authentication to “trusted” systems (I vaguely recall an article I read a while ago about a Continue reading
Welcome to Technology Short Take #83! This is a slightly shorter TST than usual, which might be a nice break from the typical information overload. In any case, enjoy!
ssh-copy-id on servers, but for network devices (leveraging Netmiko). Check out the GitHub repository.The idea of an SSH bastion host is something I discussed here about 18 months ago. For the most part, it’s a pretty simple concept (yes, things can get quite complex in some situations, but I think these are largely corner cases). For the last few months, though, I’ve been trying to use an SSH bastion host and failing, and I could not figure out why it wouldn’t work. The answer, it turns out, lies in custom SSH configurations.
In my introduction on using SSH bastion hosts (linked above)—or in just about any tutorial out there on using SSH bastion hosts—brief mention is made of adding configuration information to SSH to use the bastion host. Borrowing from my original post, if you had an instance named “private1” that you wanted to access via a bastion named “bastion”, the SSH configuration information might look like this:
Host private1
IdentityFile ~/.ssh/rsa_private_key
ProxyCommand ssh user@bastion -W %h:%p
Host bastion
IdentityFile ~/.ssh/rsa_private_key
Normally, that information would go into ~/.ssh/config, which is the default SSH configuration file.
In my case, I only allow public key authentication to “trusted” systems (I vaguely recall an article I read a while ago about a Continue reading
The idea of an SSH bastion host is something I discussed here about 18 months ago. For the most part, it’s a pretty simple concept (yes, things can get quite complex in some situations, but I think these are largely corner cases). For the last few months, though, I’ve been trying to use an SSH bastion host and failing, and I could not figure out why it wouldn’t work. The answer, it turns out, lies in custom SSH configurations.
In my introduction on using SSH bastion hosts (linked above)—or in just about any tutorial out there on using SSH bastion hosts—brief mention is made of adding configuration information to SSH to use the bastion host. Borrowing from my original post, if you had an instance named “private1” that you wanted to access via a bastion named “bastion”, the SSH configuration information might look like this:
Host private1
IdentityFile ~/.ssh/rsa_private_key
ProxyCommand ssh user@bastion -W %h:%p
Host bastion
IdentityFile ~/.ssh/rsa_private_key
Normally, that information would go into ~/.ssh/config, which is the default SSH configuration file.
In my case, I only allow public key authentication to “trusted” systems (I vaguely recall an article I read a while ago about a Continue reading
Welcome to Technology Short Take #83! This is a slightly shorter TST than usual, which might be a nice break from the typical information overload. In any case, enjoy!
ssh-copy-id on servers, but for network devices (leveraging Netmiko). Check out the GitHub repository.At Interop ITX 2017 in Las Vegas, I had the privilege to lead a half-day workshop on options for deploying containers to cloud providers. As part of that workshop, I gave four live demos of using different deployment options. Those demos—along with the slides I used for my presentation along the way—are now available to anyone who might like to try them on their own.
The slides and all the resources for the demos are available in this GitHub repository. The four demos are:
Docker Swarm on EC2: This demo leverages Terraform and Ansible to stand up and configure a Docker Swarm cluster on AWS.
Amazon EC2 Container Service (ECS): This demo uses AWS CloudFormation to create an EC2 Container Service cluster with 3 instances and an Amazon RDS instance for backend database storage.
Kubernetes on AWS using kops: Using the kops CLI tool, this demo turns up a Kubernetes cluster on AWS to show how to deploy containerized applications on Kubernetes.
Google Container Engine: The final demo shows using Google Container Engine—which is Kubernetes—to deploy an application.
In the coming weeks, I plan to recreate the demos, record them, and publish them via YouTube, so that Continue reading
At Interop ITX 2017 in Las Vegas, I had the privilege to lead a half-day workshop on options for deploying containers to cloud providers. As part of that workshop, I gave four live demos of using different deployment options. Those demos—along with the slides I used for my presentation along the way—are now available to anyone who might like to try them on their own.
The slides and all the resources for the demos are available in this GitHub repository. The four demos are:
Docker Swarm on EC2: This demo leverages Terraform and Ansible to stand up and configure a Docker Swarm cluster on AWS.
Amazon EC2 Container Service (ECS): This demo uses AWS CloudFormation to create an EC2 Container Service cluster with 3 instances and an Amazon RDS instance for backend database storage.
Kubernetes on AWS using kops: Using the kops CLI tool, this demo turns up a Kubernetes cluster on AWS to show how to deploy containerized applications on Kubernetes.
Google Container Engine: The final demo shows using Google Container Engine—which is Kubernetes—to deploy an application.
In the coming weeks, I plan to recreate the demos, record them, and publish them via YouTube, so that Continue reading