<div dir="ltr"><div><div><div><div><div><div><div>Super excited about this :)<br><br></div>Would love to get CI access from swift core team as detailed in this github issue: <a href="https://github.com/swiftdocker/docker-swift/issues/55">https://github.com/swiftdocker/docker-swift/issues/55</a><br><br></div>Helge regarding some of your concerns. They&#39;re for sure valid. But if you look at how many ppl are deploying apps to production indeed in various languages in a Docker env, they base they&#39;re dockerfile on a common image (go/rust/ruby/nodejs etc). <br><br></div>Languages such as go, you don&#39;t actually need to have go installed on your docker/server/virtualized environment. However in order to have reproducible production builds, most ppl still deploy with go as a base image and build all there project dependencies to push to a produciton environment. Is this absolutely necessary, probably not. However is still very common. You can (and I&#39;ve done this in the past) just create your linux binary in on your local machine and just deploy that (or have that built as part of your CI pipeline).<br><br></div>Other languages such as ruby/python/nodejs where you can&#39;t really have a static binary that works on any server/virtualized env without having the language toolset installed you are in a &#39;way&#39; deploying dev environments (albeit perhaps a stripped down less verbose one).<br><br></div>Our goal was to basically provide a common, easily up to date dockerized swift image that ppl can choose to deploy to production apps/development/CI whatever there heart desires :).<br><br></div>As you can see the Dockerfile isn&#39;t that complicated, just a lil bash done in a more &#39;docker&#39; friendly way that installs other depencencies necessary to actually run &#39;swift build&#39; against your app on ubuntu. This might all change when/if we have official swift installations available on package managers such as aptitude (apt get install swift), but I think Swift core isn&#39;t there yet.<br><br></div>So we&#39;re just trying to make the process a bit easier. Any suggestions to make things better/slimmer of course are welcome :)<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 22, 2017 at 4:14 PM, Helge Heß via swift-server-dev <span dir="ltr">&lt;<a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 22 Jan 2017, at 21:57, Swizzlr &lt;<a href="mailto:me@swizzlr.co">me@swizzlr.co</a>&gt; wrote:<br>
&gt; That&#39;s a great question. We&#39;re satisfied that the 400MB image size isn&#39;t _too_ onerous for the majority of users - especially since one of the benefits of Docker is that per host, that 400MB will only be used once (copy on write FS) - but there can never be enough done.<br>
<br>
</span>Well, that doesn’t address my question &#39;What does &#39;Dockerizing Swift’ mean?’. Which is why that container is even needed. Anyone can choose his base distribution on size or features and install Swift in like 3 lines of bash. What is the idea behind this? Does it anything extra beyond unpacking the tarball?<br>
<span class=""><br>
&gt; We have an issue open that addresses this exact topic: <a href="https://github.com/swiftdocker/docker-swift/issues/48" rel="noreferrer" target="_blank">https://github.com/<wbr>swiftdocker/docker-swift/<wbr>issues/48</a>. Of particular interest is how to export a Swift binary that is statically linked; perhaps a base image containing the Swift runtime support libs (ICU, Foundation, Core etc) would be ideal.<br>
<br>
</span>In case this isn’t clear my primary concern is not just size but rather hackability. A Swift Server app container should really just have the stuff required to host that specific binary to avoid attack vectors.<br>
<br>
But yes, this GitHub issue addresses the exact topic I have in mind :-)<br>
<br>
And I don’t think it should be addressed at the Docker level. I guess the Swift tarball needs to be split up into a runtime and a development environment. Kinda like Java JRE and JDK.<br>
<span class=""><br>
&gt; In case I haven&#39;t covered every base: the final benefit is a reproducible development environment, one that is the same on our machines and the server.<br>
<br>
</span>¯\_(ツ)_/¯<br>
<br>
I hope you don’t really deploy dev environments to a server ;-&gt;<br>
<br>
hh<br>
<div class="HOEnZb"><div class="h5"><br>
&gt;<br>
&gt; Tom<br>
&gt;<br>
&gt; Sent from my iPhone<br>
&gt;<br>
&gt; On 22 Jan 2017, at 19:47, Helge Heß via swift-server-dev &lt;<a href="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; Hi,<br>
&gt;&gt;<br>
&gt;&gt; someone told me about this too. I don’t want to lower the work involved in that, but I suppose I just don’t understand what this is about. What does &#39;Dockerizing Swift’ mean? Isn’t that just<br>
&gt;&gt;<br>
&gt;&gt;  wget &lt;swift-tarball&gt;<br>
&gt;&gt;  tar zxf &lt;swift-tarball&gt;<br>
&gt;&gt;  export PATH=$PATH:swift-tarball<br>
&gt;&gt;<br>
&gt;&gt; ? Or does it anything extra?<br>
&gt;&gt;<br>
&gt;&gt; I think something which would be really helpful is a docker setup that is separating the build and the deployment step. That is, if I deploy a Swift Server app the last thing I want is to ship Swift llvm or clang, etc, but just the app and the runtime. Is someone working on something like that already?<br>
&gt;&gt;<br>
&gt;&gt; hh<br>
&gt;&gt;<br>
&gt;&gt;&gt; On 22 Jan 2017, at 19:18, Swizzlr via swift-server-dev &lt;<a href="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; In case any you aren&#39;t/weren&#39;t subscribed to the Swift Users list. Link to thread: <a href="https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20170116/004470.html" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>pipermail/swift-users/Week-of-<wbr>Mon-20170116/004470.html</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Sent from my iPhone<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Begin forwarded message:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; From: Swizzlr &lt;<a href="mailto:me@swizzlr.co">me@swizzlr.co</a>&gt;<br>
&gt;&gt;&gt;&gt; Date: 21 January 2017 at 22:10:59 GMT<br>
&gt;&gt;&gt;&gt; To: swift-users &lt;<a href="mailto:swift-users@swift.org">swift-users@swift.org</a>&gt;<br>
&gt;&gt;&gt;&gt; Subject: Announcement: Official Docker Image for Swift now available<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Hello all,<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I&#39;m pleased to announce that with the assistance of many, many people (see below), we have released an “official&quot; Docker image for Swift.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; The image contains everything needed to compile and run a Swift application, reliably and reproducibly. It’s based on Ubuntu 16.04 and has been used in production for many months now. A Docker library image such as this one occupies the top level namespace, so that you can simply write “FROM swift” to refer to the image. It has received extensive auditing for best practices and security by Docker experts, and will be maintained by a dedicated team of volunteers.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I would like to encourage everyone interested to ask questions and offer improvements over on the Github repo. Personally, I want to offer my thanks to Haris Amin and Oliver Letterer for their early and pioneering work on Dockerizing Swift, Tianon Gravi for his patient and informative feedback while refining the image; and all those who have contributed to its development.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Happy coding – I hope you make something excellent with this.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Tom<br>
&gt;&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt;&gt; swift-server-dev mailing list<br>
&gt;&gt;&gt; <a href="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a><br>
&gt;&gt;&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-server-<wbr>dev</a><br>
&gt;&gt;<br>
&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt; swift-server-dev mailing list<br>
&gt;&gt; <a href="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a><br>
&gt;&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-server-<wbr>dev</a><br>
<br>
______________________________<wbr>_________________<br>
swift-server-dev mailing list<br>
<a href="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-server-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>