Your Docker agenda for VMworld 2014

Next week starts the gigantic VMworld conference at the Moscone Center in San Francisco, California. If you are attending the conference, come visit us at the Docker booth #230 and make sure to attend the following Docker-related talks, demos, discussions and meetups where you can meet and chat with fellow Dockerites:

docker-talks

Monday, August 25th:

3:30 PM – 4:30 PM, Moscone West, Room 2014

VMware NSX for Docker, Containers & Mesos by Aaron Rosen (Staff Engineer, VMware) and Somik Behera (NSX Product Manager, VMware)

This session will provide a recipe for architecting massively elastic applications, be it big data applications or developer environments such as Jenkins on top of VMware SDDC Infrastructure. We will describe the use of app isolation technologies such as LxC & Docker together with Resource Managers such as Apache Mesos & Yarn to deliver an Open Elastic Applications & PaaS for mainstream apps such as Jenkins as well as specialized big data applications. We will cover a customer case study that leverages VMware SDDC to create an Open Elastic PaaS leveraging VMware NSX for Data communication fabric.

 

5:30 PM – 6:30 PM, Moscone West, Room 2006

VMware and Docker – Better Together by Ben Golub (CEO, Continue reading

Orchestrating Docker containers in production using Fig

In the last blog post about Fig we showed how you could define and run a multi-container app locally.

We’re now going to show you how you can deploy this app to production. Here’s a screencast of the whole process:

Let’s continue from where we left off in the last blog post. First, we want to put the code we wrote up onto GitHub. You’ll need to initialize and commit your code into a new Git repository.

$ git init
$ git add .
$ git commit -m "Initial commit"

Then create a new repository on GitHub and follow the instructions for how to set up a remote on your local GitHub repository. For example, if your repository were called bfirsh/figdemo, you’d run these commands:

$ git remote add origin [email protected]:bfirsh/figdemo.git
$ git push -u origin master

Next, you’ll need to get yourself a server to host your app. Any cloud provider will work, so long as it is running Ubuntu and available on a public IP address.

Log on to your server using SSH and follow the instructions for installing Docker and Fig on Ubuntu.

$ ssh root@[your server’s IP address]
# curl -sSL https://get.docker.io/ubuntu/ |  Continue reading

What is an Automatic Transfer Switch (Power)?

In response to the power redundancy article I wrote yesterday, a few comments came in. One of them (thanks, Mike!) mentioned an automatic transfer switch (ATS), a useful tool in a redundant power strategy. What is an ATS? There are many types of electrical transfer switches whose primary purpose is to divert the […]

Announcing Docker 1.2.0

The hardworking folk at Docker, Inc. are proud to announce the release of version 1.2.0 of Docker. We’ve made improvements throughout the Docker platform, including updates to Docker Engine, Docker Hub, and our documentation.

1.2.0

Highlights include these new features:

restart policies

We added a --restart flag to docker run to specify a restart policy for your container. Currently, there are three policies available:

  • no – Do not restart the container if it dies. (default)
  • on-failure – Restart the container if it exits with a non-zero exit code.
    • Can also accept an optional maximum restart count (e.g. on-failure:5).
  • always – Always restart the container no matter what exit code is returned.

This deprecates the --restart flag on the Docker daemon.

A few examples:
  • Redis will endlessly try to restart if the container exits
docker run --restart=always redis
  • If redis exits with a non-zero exit code, it will try to restart 5 times before giving up:
docker run --restart=on-failure:5 redis

–cap-add –cap-drop

Currently, Docker containers can either be given complete capabilities or they can all follow a whitelist of allowed capabilities while dropping all others. Further, previously, using --privileged would grant all capabilities inside a container, rather than applying a whitelist. This was not Continue reading

Missing Synergies & HP’s SDN

As someone who’s been monitoring HP’s SDN strategy for years now, news that Bethany Mayer is headed to Ixia is rather interesting. Despite HP’s networking division having had some successes and gaining small bits of market share here and there, the fact they they are leaders in the SDN space seems to go unnoticed by the […]

Leveraging Cisco NX-API with Ansible to Make Your Life Easier

I had a conversation recently with someone who has more of a sysadmin background.  We started talking about the intersection of DevOps and networking and while his environment wasn’t large, there was one pain point he talked about – he doesn't have access to the network switches to ensure they are configured properly for “his” servers and to ensure packets aren't being dropped, etc. when there are issues with the application, server, or network.  And by the way, he really doesn't want access to the data center switches, because after all, many fear logging into network devices that are in production.  

Could DevOps and network automation help here?
In fact, the answer is yes.  The goal is to get the right data into the right hands as quick as possible.  An automation platform can be used to query the switch to get the exact data the admin needs.  For those that have help desks supporting large campus networks, the same philosophy can be used there as well.   Help desk, junior admins, and cross-functional team members can now get what they need in just a few seconds.

In order to test this out, I’ve Continue reading

FabricPath Multidestination Trees

    FabricPath has many advantages over the classical Spanning Tree Protocol. Mainly because it can use ECMP (Equal Cost Multi Paths) Routing. For unicast frames it uses the well known Switch-ID that is inserted in a FabricPath header. This will be explained in a future post for sure. I have been intrigued regarding how multicast […]

Load Balancing Lab setup

Virtual Loadblanacers

Nowadays, you don't need a physical load balancer to setup a lab. Almost each and every vendor offers a "virtual appliance", which is just their appliance repacked as a virtual machine:

Here is a list of few such virtual loadbalancers:

There are even opensource alternatives such as:

So building a virtual lab on a laptop is just one download away, isn't it?

No, there are to missing pieces: Network topology with a router and web servers with content which is suitable for such labs.

Luckily for you, I have just setup such a lab, and I welcome you to use it as well.

Network topology

Basic topology

The usual loadbalancer lab looks like this:

But this is not how loadbalncers are usually deployed. And its also not the best way to deploy them, as not all traffic needs to go through the loadbalancer.

Realistic topology

Topology Continue reading

Quick Take: Wider Channel Widths Are Flashy but Not Efficient

I've been thinking of writing a well-articulated blog post on why the preference for high-density Wi-Fi networks is smaller channel width over larger channel width. This post is NOT that.

Instead, I was on Twitter articulating some of the logical points why smaller channel widths provide better aggregate capacity than larger channel widths (assuming you deploy enough radios and take advantage of all the spectrum at your disposal). Here is a quick recap of those points.

You might want to reference my SNR to MCS Index Mapping Table, which shows why larger channels result in a reduction in modulation rate that can often offset the gain from using the wider bandwidth in the first place. And my 802.11ac Receiver Sensitivity charts show that you have to have a really great signal strength for wider channels to even be considered, but watch out in your design because overcompensating to achieve higher signal strength will increase co-channel interference (CCI) which travels a LONG ways! Finally, my post on 802.11ac Adjacent Channel Interference (ACI) shows that wider channels create more ACI than smaller channels, and ACI is even more detrimental and unfriendly than CCI. Therefore, radio receivers require greater adjacent channel Continue reading

Democratizing the Networking Industry beyond the Two Party System

When it comes to the networking industry and purchasing a network device, a user typically has two choices: Party D and Party R.

Sure, there are other parties out there, but they usually don’t make the ballot for one reason or another. Even when you are not a “hardcore” supporter of either party, you feel stuck in one of those camps since you cannot partially “vote,” much less mix-and-match, as both parties are incompatible with each other.

What if this doesn’t have to be the case?

In this new world democracy, what if you could apportion your vote in a piecemeal fashion? In essence, taking the bits from one party combined with those of another party to create a new candidate tailored for your needs.

For the last 18 months or so, the Open Compute Project (OCP) Networking Group has been further validating and accelerating the adoption of this new reality of a disaggregated network design where the network device is separated from the network operating system (NOS) that powers the device. At the heart of this is a little piece of OCP software called ONIE (Open Network Install Environment), a key innovation by Cumulus Networks and released Continue reading

Network Break 15

The Network Break returns with Show 15.

Author information

Greg Ferro

Greg Ferro is a Network Engineer/Architect, mostly focussed on Data Centre, Security Infrastructure, and recently Virtualization. He has over 20 years in IT, in wide range of employers working as a freelance consultant including Finance, Service Providers and Online Companies. He is CCIE#6920 and has a few ideas about the world, but not enough to really count.

He is a host on the Packet Pushers Podcast, blogger at EtherealMind.com and on Twitter @etherealmind and Google Plus.

TwitterFacebookGoogle+

The post Network Break 15 appeared first on Packet Pushers Podcast and was written by Greg Ferro.

Windows ISATAP Client, Part 2

In Part 1 we discussed how to turn off ISATAP on Windows host—which is a great idea.  Turning off unnecessary components of your network simplifies everything.  But ISATAP can be useful in certain scenarios.  For instance, if you want to test an application on IPv6 you clearly don’t want to turn on IPv6 everywhere and […]

Author information

Dan Massameno

Dan Massameno is the president and Chief Engineer at Leaf Point, a network engineering firm in Connecticut.

The post Windows ISATAP Client, Part 2 appeared first on Packet Pushers Podcast and was written by Dan Massameno.

802.11ac Receiver Sensitivity

Following my previous post regarding typical SNR to MCS rate mappings for Wi-Fi clients, an interesting discussion was held on Twitter regarding the effects of increased channel width on the ability of a client to decode frames at any given SNR. Long story short, wider channels increase the noise power captured by the receiving radio which reduces its SNR. For every doubling of channel width, you require 3dB better signal to achieve the same MCS rate.

George Ou created a chart showing the relative range of each MCS rate based at various channel widths:



Following up on his work, I thought it would be useful to provide some context around these coverage ranges by referencing it against a typical noise floor of -93 dBm found in many environments. Using this noise floor and the SNR to MCS rate mapping table, combined with the relative coverage ranges (based on RF signal propagation using the inverse square law) we can visualize what data rates a typical 802.11ac radio will experience at various RSSI and SNR signal levels for each channel Continue reading

Announcing DockerCon Europe 2014

Flag_of_Europe.svg

Today we are very happy to announce DockerCon Europe 2014, the first official Docker conference organized in Europe, by both Docker, Inc. and members of the community. The conference will take place in Amsterdam, at the NEMO science center, December 4th and 5th.

Nemo_Science_Center_1

We will also have a full day or training prior to the conference, led by Jérôme Petazzoni on December 3rd.

The official website is still under construction as we are finalizing the last details, but today we can announce that the Docker team will be present as well as incredible speakers from the Docker community including:

Call for papers opens today, you can submit your talk here. If you are interested in our sponsorship options, please contact us at [email protected].

We also want to give a special thanks to Pini Reznik, Harm Boertien, Mark Coleman, Maarten Dirkse and the Docker Amsterdam community, who are working with us to bring the best of Docker to Europe.

Save the dates and stay tuned for more announcements!

VRF based path selection

In this post I will be showing you how its possible to use different paths between your PE routers on a per VRF basis.

This is very useful if you have customers you want to “steer” away from your normal traffic flow between PE routers.
For example, this could be due to certain SLA’s.

I will be using the following topology to demonstrate how this can be done:

Topology

A short walkthrough of the topology is in order.

In the service provider core we have 4 routers. R3, XRv-1, XRv-2 and R4. R3 and R4 are IOS-XE based routers and XRv-1 and XRv-2 are as the name implies, IOS-XR routers. There is no significance attached to the fact that im running two XR routers. Its simply how I could build the required topology.

The service provider is running OSPF as the IGP, with R3 and R4 being the PE routers for an MPLS L3 VPN service. On top of that, LDP is being used to build the required LSP’s. The IGP has been modified to prefer the northbound path (R3 -> XRv-1 -> R4) by increasing the cost of the R3, XRv-2 and R4 to 100.

So by default, traffic between Continue reading

Pmacct: the Traffic Analysis Tool with Unpronounceable Name

SDN evangelists talking about centralized traffic engineering, flow steering or bandwidth calendaring sometimes tend to gloss over the first rule of successful traffic engineering: Know Thy Traffic.

In a world ruled by OpenFlow you’d expect the OpenFlow controller to know all the traffic; in more traditional networks we use technologies like NetFlow, sFlow or IPFIX to report the traffic statistics – but regardless of the underlying mechanism, you need a tool that will collect the statistics, aggregate them in a way that makes them usable to the network operators, report them, and potentially act on the deviations.

Read more ...
1 … 3,569 3,570 3,571 3,572 3,573 … 3,694