# Idea: runtime/slim images **URL:** \ **Category:** Docker\ **Created:** [April 5, 2019, 4:15pm UTC](https://forums.swift.org/t/idea-runtime-slim-images/22695 "2019-04-05T16:15:51Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![IanPartridge](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ianpartridge/32/434_2.png) [@IanPartridge](https://forums.swift.org/u/IanPartridge)\ **Post date:** [April 5, 2019, 4:15pm UTC](https://forums.swift.org/t/idea-runtime-slim-images/22695/1 "2019-04-05T16:15:51Z")
Currently, the Swift Docker images come "batteries included", with everything users need to build and run Swift programs, run the REPL etc. This means that they are necessarily quite large. Other languages also offer "slim" images, which are images that only contain what's required to _run_ a program. For example, in the case of Java this means the slim image includes the JVM but not the Java compiler. For Node.js it includes the runtime but not `npm`. I would like us to publish slim images for Swift as well and I have prototyped what such images would look like. There would be two main differences from the current images. 1. The system package requirements would be much lighter, just: `libatomic1 libbsd0 libcurl4 libxml2 tzdata` I think. 2. We would not include the entire Swift toolchain, just the `/usr/lib/swift/linux` shared libraries from the tar.gz. Taking this approach, my slim image is ~250MB, in comparison to 1.37GB for the full image. One nice thing about this is it means users can use a multi-stage `Dockerfile` to build their app, something like this: ```swift FROM swift:5.0 as builder WORKDIR /root COPY . . RUN swift build FROM swift:5.0-slim WORKDIR /root COPY --from=builder /root . CMD [".build/x86_64-unknown-linux/debug/docker-test"] ``` What do people think about this? ---
**Author:** ![johannesweiss](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/johannesweiss/32/38183_2.png) [@johannesweiss](https://forums.swift.org/u/johannesweiss)\ **Post date:** [April 5, 2019, 4:22pm UTC](https://forums.swift.org/t/idea-runtime-slim-images/22695/2 "2019-04-05T16:22:27Z")
I think that's a great idea. Will `lldb` work in the `-slim` ones? ---
**Author:** ![IanPartridge](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ianpartridge/32/434_2.png) [@IanPartridge](https://forums.swift.org/u/IanPartridge)\ **Post date:** [April 5, 2019, 4:42pm UTC](https://forums.swift.org/t/idea-runtime-slim-images/22695/3 "2019-04-05T16:42:54Z")
In my current prototype, no. The problem is that `lldb` depends on `liblldb.so` which is 130MB, plus `libpython2.7`... So the slim image rapidly becomes not so slim after all... Perhaps the closest comparison to Swift is Rust (as a compiled language built on LLVM). `rust:slim` doesn't include a debugger. Does anyone have experience from deploying containers in production. Is a debugger essential? For Golang I thought it was common to just deploy the static binary with nothing else in the container. ---
**Author:** ![Keith](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/keith/32/291_2.png) [@Keith](https://forums.swift.org/u/Keith)\ **Post date:** [April 5, 2019, 4:51pm UTC](https://forums.swift.org/t/idea-runtime-slim-images/22695/4 "2019-04-05T16:51:54Z")
We run tests in slimmed down containers that we build ourselves. I've found sometimes having a debugger is useful but I'd rather be forced to manually install it in the container when I needed it than incur the download time overhead. ---
**Author:** ![johannesweiss](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/johannesweiss/32/38183_2.png) [@johannesweiss](https://forums.swift.org/u/johannesweiss)\ **Post date:** [April 5, 2019, 5:21pm UTC](https://forums.swift.org/t/idea-runtime-slim-images/22695/5 "2019-04-05T17:21:53Z")
> [@IanPartridge](#): > > In my current prototype, no. The problem is that `lldb` depends on `liblldb.so` which is 130MB, plus `libpython2.7` ... So the slim image rapidly becomes not so slim after all... Hmm, that means no symbolicated stack traces and no debugging at all... Is that useful? > [@IanPartridge](#): > > Perhaps the closest comparison to Swift is Rust (as a compiled language built on LLVM). `rust:slim` doesn't include a debugger. Hmm, Rust just doesn't have the great lldb support that Swift has, so it's less useful anyway... > [@IanPartridge](#): > > Does anyone have experience from deploying containers in production. Is a debugger essential? For Golang I thought it was common to just deploy the static binary with nothing else in the container. We run [`symbolicate-swift-fatal`](https://github.com/apple/swift/blob/master/utils/symbolicate-linux-fatal) to symbolicate the stack traces after a crash which requires lldb. ---
**Author:** ![Mordil](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/mordil/32/5840_2.png) [@Mordil](https://forums.swift.org/u/Mordil)\ **Post date:** [April 5, 2019, 5:34pm UTC](https://forums.swift.org/t/idea-runtime-slim-images/22695/6 "2019-04-05T17:34:56Z")
> [@Keith](#): > > I've found sometimes having a debugger is useful but I'd rather be forced to manually install it in the container when I needed it than incur the download time overhead. What's the cost / overhead of adding a `slim-lldb` flavor? - `swift:5.0` - runtime & compiler, recommended to be used in multi-stage builds - `swift:5.0:slim` - just the runtime and handful of system libraries - `swift:5.0:slim-lldb` - same as above, but with lldb ---
**Author:** ![tanner0101](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tanner0101/32/675_2.png) [@tanner0101](https://forums.swift.org/u/tanner0101)\ **Post date:** [April 5, 2019, 10:33pm UTC](https://forums.swift.org/t/idea-runtime-slim-images/22695/7 "2019-04-05T22:33:09Z")
> [@johannesweiss](#): > > We run [`symbolicate-swift-fatal`](https://github.com/apple/swift/blob/master/utils/symbolicate-linux-fatal) to symbolicate the stack traces after a crash which requires lldb. Maybe we could include this file in the `slim-lldb` image, too? Is there anyway with Docker that we could run it on crash output automatically? ---
**Author:** ![johannesweiss](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/johannesweiss/32/38183_2.png) [@johannesweiss](https://forums.swift.org/u/johannesweiss)\ **Post date:** [April 6, 2019, 9:07am UTC](https://forums.swift.org/t/idea-runtime-slim-images/22695/8 "2019-04-06T09:07:03Z")
> [@tanner0101](#): > > > We run [`symbolicate-swift-fatal`](https://github.com/apple/swift/blob/master/utils/symbolicate-linux-fatal) to symbolicate the stack traces after a crash which requires lldb. > > Maybe we could include this file in the `slim-lldb` image, too? Is there anyway with Docker that we could run it on crash output automatically? We should! ---
**Author:** ![MrLotU](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/mrlotu/32/1457_2.png) [@MrLotU](https://forums.swift.org/u/MrLotU)\ **Post date:** [April 6, 2019, 2:31pm UTC](https://forums.swift.org/t/idea-runtime-slim-images/22695/9 "2019-04-06T14:31:02Z")
All of this sounds really promising! I know that at my work, one big reason not to use Swift is because of the huge docker images. This would greatly improve this 😃 ---
**Author:** ![Joe\_Smith](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joe_smith/32/2552_2.png) [@Joe\_Smith](https://forums.swift.org/u/Joe_Smith)\ **Post date:** [April 7, 2019, 6:31pm UTC](https://forums.swift.org/t/idea-runtime-slim-images/22695/10 "2019-04-07T18:31:27Z")
A supported `slim` version for release would be excellent; for what it's worth I'd almost always want to run the version with `lldb` support in production to capture the "one weird crash" in the wild and get as much data from a problem as possible. Schlepping over and extra ~200m is worth it from my experience. ---
**Author:** ![Slava\_Pestov](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/slava_pestov/32/30204_2.png) [@Slava\_Pestov](https://forums.swift.org/u/Slava_Pestov)\ **Post date:** [April 8, 2019, 2:09am UTC](https://forums.swift.org/t/idea-runtime-slim-images/22695/11 "2019-04-08T02:09:32Z")
Assuming you're going to be looking at a core dump offline, why is it necessary to include lldb as part of the docker image at all? ---
**Author:** ![Joe\_Smith](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joe_smith/32/2552_2.png) [@Joe\_Smith](https://forums.swift.org/u/Joe_Smith)\ **Post date:** [April 8, 2019, 2:14am UTC](https://forums.swift.org/t/idea-runtime-slim-images/22695/12 "2019-04-08T02:14:49Z")
Ah, thanks for the save & great question. I misunderstood what was being provided. I’d run most containers as `slim`, and give best-effort to keeping a core dump for offline review later (using whatever container orchestration system/tools to do so). You’re correct in I’d like to have an lldb-friendly container occasionally, but since I’d have core dumps from a `slim` container I would not care to bring along debugging tools for normal, prod containers. ---
**Author:** ![johannesweiss](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/johannesweiss/32/38183_2.png) [@johannesweiss](https://forums.swift.org/u/johannesweiss)\ **Post date:** [April 8, 2019, 11:25am UTC](https://forums.swift.org/t/idea-runtime-slim-images/22695/13 "2019-04-08T11:25:09Z")
> [@Slava\_Pestov](#): > > Assuming you're going to be looking at a core dump offline it's online. In server environments you typically want to have your crash reports at least in Splunk (I say 'at least' because you might have a better story around crash reports but baseline would be Splunk/ELK/...) etc, and that's only useful if symbolicated. We run `./binary | symbolicate-swift-fatal ./binary` so the crash output is already symbolicated when it hits stdout/err which gets send to splunk anyway. Of course, we could build infrastructure to have access to the un-symbolicated stack trace, all binaries and also a way to identify which crash came from what deployment. Then we could have some software that then takes all this information and symbolicates, but that's just a lot of work for something that's much easier done straight away. Arguably, this all shouldn't be necessary and all the stack traces should come symbolicated straight away. ---
**Author:** ![IanPartridge](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ianpartridge/32/434_2.png) [@IanPartridge](https://forums.swift.org/u/IanPartridge)\ **Post date:** [April 9, 2019, 3:47pm UTC](https://forums.swift.org/t/idea-runtime-slim-images/22695/15 "2019-04-09T15:47:00Z")
Thanks everyone for your feedback. It's really great to hear people's interest in this. > [@johannesweiss](#): > > We run `./binary | symbolicate-swift-fatal ./binary` so the crash output is already symbolicated when it hits stdout/err which gets send to splunk anyway. Doing this requires Python to be installed as well, which will make the image even larger. Even the full `swift:5.0` image doesn't include Python - if we're making Python a requirement maybe `swift:5.0` should start `FROM python`... (joke) > [@johannesweiss](#): > > Arguably, this all shouldn't be necessary and all the stack traces should come symbolicated straight away. This. Does anyone know what prevents that at the moment? I'm afraid I have no idea. > [@tanner0101](#): > > Maybe we could include this file [`symbolicate-swift-fatal`] in the `slim-lldb` image, too? I think we should go further, and include it in the Linux release .tar.gz, as its so useful. Then it will be in the main `swift:5.0` Docker image. It's not there today. What do people think? > [@Mordil](#): > > What's the cost / overhead of adding a `slim-lldb` flavor? I don't know whether Docker would accept that - the other languages I've seen only have two flavours: normal and slim. But we could ask, if having a third image is the solution we prefer. Personally I'd like to try hard to avoid it as it complicates things for users and image maintainers. > [@Slava\_Pestov](#): > > Assuming you're going to be looking at a core dump offline, why is it necessary to include lldb as part of the docker image at all? You're right, it isn't for offline analysis as you can `docker commit` the container containing the core file and then load the core into another image that contains LLDB for analysis. > [@papercup](#): > > this sounds great, but doesn‘t this already exist with the images of ibm: [https://github.com/IBM-Swift/swift-ubuntu-docker](https://github.com/IBM-Swift/swift-ubuntu-docker) > (they have a builder and runtime image) > Or what would be the difference? IBM has maintained our own `build` and `run` images for several years. The images have some historical quirks though and we're keen to improve the upstream images so the whole community benefits. ---
**Author:** ![cmlccie](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/cmlccie/32/4868_2.png) [@cmlccie](https://forums.swift.org/u/cmlccie)\ **Post date:** [April 9, 2019, 8:13pm UTC](https://forums.swift.org/t/idea-runtime-slim-images/22695/16 "2019-04-09T20:13:58Z")
> [@IanPartridge](#): > > I don't know whether Docker would accept that - the other languages I've seen only have two flavours: normal and slim. But we could ask, if having a third image is the solution we prefer. Personally I'd like to try hard to avoid it as it complicates things for users and image maintainers. This is pretty standard fare in the Docker container world. You typically can post as many images and tags as are needed. Though the tag list should be kept as small as possible (to reduce complexity). The tags and their proper usage should be clearly and concisely communicated in the README. I for one will benefit from a slim image. The value of including the debugger in the slim image isn’t worth the increased image size for something that is an irregular activity (for me) - especially as there are other options as noted above. ---
**Author:** ![tomerd](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tomerd/32/3402_2.png) [@tomerd](https://forums.swift.org/u/tomerd)\ **Post date:** [April 10, 2019, 12:27am UTC](https://forums.swift.org/t/idea-runtime-slim-images/22695/17 "2019-04-10T00:27:02Z")
> [@johannesweiss](#): > > Arguably, this all shouldn't be necessary and all the stack traces should come symbolicated straight away. who is the right person that can answer if this is possible? it will drastically improve debuggability imo ---
**Author:** ![IanPartridge](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ianpartridge/32/434_2.png) [@IanPartridge](https://forums.swift.org/u/IanPartridge)\ **Post date:** [April 10, 2019, 11:04am UTC](https://forums.swift.org/t/idea-runtime-slim-images/22695/18 "2019-04-10T11:04:54Z")
I've opened [[SR-10439] Ship symbolicate-linux-fatal · Issue #290 · apple/swift-docker · GitHub](https://bugs.swift.org/browse/SR-10439) to track shipping `symbolicate-linux-fatal` as part of the releases. ---
**Author:** ![IanPartridge](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ianpartridge/32/434_2.png) [@IanPartridge](https://forums.swift.org/u/IanPartridge)\ **Post date:** [April 10, 2019, 11:06am UTC](https://forums.swift.org/t/idea-runtime-slim-images/22695/19 "2019-04-10T11:06:30Z")
> [@cmlccie](#): > > This is pretty standard fare in the Docker container world. You typically can post as many images and tags as are needed. This is true for normal accounts on Docker Hub, but the Swift images are part of the Docker [Official Images](https://docs.docker.com/docker-hub/official_images/) program, which is curated by Docker to ensure best practices etc. So we'd need to work with Docker to make this happen, if we want it. ---
**Author:** ![cmlccie](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/cmlccie/32/4868_2.png) [@cmlccie](https://forums.swift.org/u/cmlccie)\ **Post date:** [April 18, 2019, 2:25am UTC](https://forums.swift.org/t/idea-runtime-slim-images/22695/20 "2019-04-18T02:25:00Z")
Yes, and it doesn't appear to be an issue for _official_ images either. Just look at the [Python](https://hub.docker.com/_/python) image(s). It's a sizable matrix of: - `python:` - `python:-slim` - `python:-alpine` - `python:-windowsservercore` 🕶 ---
**Author:** ![IanPartridge](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ianpartridge/32/434_2.png) [@IanPartridge](https://forums.swift.org/u/IanPartridge)\ **Post date:** [April 18, 2019, 8:01am UTC](https://forums.swift.org/t/idea-runtime-slim-images/22695/21 "2019-04-18T08:01:18Z")
Yes, I wasn't saying it was impossible, just that it's not entirely within our gift. [Next page](https://forums.swift.org/t/idea-runtime-slim-images/22695.md?page=2)