<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Macvlan - vo.rs</title><link>https://vo.rs/tags/macvlan/</link><description>Latest from the Macvlan desk at vo.rs.</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.</copyright><lastBuildDate>Sat, 16 Mar 2024 16:59:00 +0000</lastBuildDate><atom:link href="https://vo.rs/tags/macvlan/" rel="self" type="application/rss+xml"/><item><title>MACVLAN and IPVLAN: Giving Containers Real IPs</title><link>https://vo.rs/story/macvlan-and-ipvlan-giving-containers-real-ips/</link><description>&lt;p&gt;By default a Docker container lives behind the host like a flat in a building with one shared front door. It gets a private address on an internal bridge network, and when it talks to the outside world the host translates its traffic — the same NAT trick your router does, one layer down. For most services that&amp;rsquo;s exactly right: you publish a port, the host forwards it, done. But some containers are miserable behind that front door, and for them you want the container to have its own address directly on your LAN, its own knock on the network, visible to every other device as a peer. That&amp;rsquo;s what &lt;strong&gt;MACVLAN&lt;/strong&gt; and &lt;strong&gt;IPVLAN&lt;/strong&gt; deliver, and knowing when to reach for them saves a lot of fighting with port mappings that were never going to work.&lt;/p&gt;</description><pubDate>Sat, 16 Mar 2024 16:59:00 +0000</pubDate></item></channel></rss>