We can untar directly into the root of the filesystem, so no path modification nor rsync. I think it's slightly more elegant.

https://github.com/swizzlr/docker-swift/blob/master/Dockerfile#L9

When you try to run a Swift binary which is linked dynamically, it won't find the Swift shared libraries in the current Docker image.

You may want to add this:

RUN bash -c "echo '/usr/lib/swift/linux' > /etc/ld.so.conf.d/swift.conf;\
             echo '/usr/lib/swift/clang/lib/linux' >> /etc/ld.so.conf.d/swift.conf;\
             echo '/usr/lib/swift/pm' >> /etc/ld.so.conf.d/swift.conf;\
             ldconfig"

Overview

Swift REPL requires LLDB. LLDB requires some elevated privileges.

Objectives

• Clearly define the elevated privileges required by LLDB's REPL
• Provide clear and simple documentation in the README on how to access the REPL, including an explanation of the rationale required
• Provide alternative examples of using the docker image that don't involve the REPL/elevated privileges (e.g. Dockerfiles, invoking scripts in Swift)

建议把openssl和uuid加入镜像。

Hi,
are there any plans to have official docker image for ARM devices?

TimeZone(identifier: "Europe/Paris") returns nil and TimeZone.knownTimeZoneIdentifiers returns an empty array.

When I manually installed the tzdata apt package both worked as expected.

I can create a PR to fix this. Just let me know.

@OliverLetterer @swizzlr I think both of you had this in your versions. Either one of you wanna pick this up?

Is there a way to make the creation of new images, based on new versions, automated? Something that checks for newer versions of Swift once a day and builds new images as needed?

It looks like you can't use the package manager inside the swift docker container anymore, because the lib curl dependency isn't present:

$ docker images | grep swiftdocker
swiftdocker/swift        latest              d366469c2806        5 hours ago         988.3 MB

$ docker run -ti swiftdocker/swift

root@5cda607f685c:/# swift --version
Swift version 3.0-dev (LLVM f54fa77021, Clang 9a77bc41b8, Swift 1a88c86f39)
Target: x86_64-unknown-linux-gnu

root@5cda607f685c:/# swift build --help
/usr/bin/swift-build: error while loading shared libraries: libcurl.so.4: cannot open shared object file: No such file or directory

Can we get away with less packages? Any of them redundant? rsync, libxml2?

hi there i am useing this Docker file for my Perfect sercer side app i got some error would you like to check it please

RUN apt-get -q update && \
    apt-get -q install -y \
    make \
    libc6-dev \
    clang-3.8 \
    curl \
    libedit-dev \
    python2.7 \
    python2.7-dev \
    libicu-dev \
    libssl-dev \
    libxml2 \
    git \
    imagemagick \
    libcurl4-openssl-dev \
    pkg-config \
    && update-alternatives --quiet --install /usr/bin/clang clang /usr/bin/clang-3.8 100 \
    && update-alternatives --quiet --install /usr/bin/clang++ clang++ /usr/bin/clang++-3.8 100 \
    && rm -r /var/lib/apt/lists/*

    # Everything up to here should cache nicely between Swift versions, assuming dev dependencies change little
    ARG SWIFT_PLATFORM=ubuntu16.04
    ARG SWIFT_BRANCH=swift-4.0-release
    ARG SWIFT_VERSION=swift-4.0-RELEASE

    ENV SWIFT_PLATFORM=$SWIFT_PLATFORM \
        SWIFT_BRANCH=$SWIFT_BRANCH \
        SWIFT_VERSION=$SWIFT_VERSION

    # Download GPG keys, signature and Swift package, then unpack, cleanup and execute permissions for foundation libs
    RUN SWIFT_URL=https://swift.org/builds/$SWIFT_BRANCH/$(echo "$SWIFT_PLATFORM" | tr -d .)/$SWIFT_VERSION/$SWIFT_VERSION-$SWIFT_PLATFORM.tar.gz \
        && curl -fSsL $SWIFT_URL -o swift.tar.gz \
        && curl -fSsL $SWIFT_URL.sig -o swift.tar.gz.sig \
        && export GNUPGHOME="$(mktemp -d)" \
        && set -e; \
            for key in \
          # pub   4096R/412B37AD 2015-11-19 [expires: 2017-11-18]
          #       Key fingerprint = 7463 A81A 4B2E EA1B 551F  FBCF D441 C977 412B 37AD
          # uid                  Swift Automatic Signing Key #1 <[email protected]>
              7463A81A4B2EEA1B551FFBCFD441C977412B37AD \
          # pub   4096R/21A56D5F 2015-11-28 [expires: 2017-11-27]
          #       Key fingerprint = 1BE1 E29A 084C B305 F397  D62A 9F59 7F4D 21A5 6D5F
          # uid                  Swift 2.2 Release Signing Key <[email protected]>
              1BE1E29A084CB305F397D62A9F597F4D21A56D5F \
          # pub   4096R/91D306C6 2016-05-31 [expires: 2018-05-31]
          #       Key fingerprint = A3BA FD35 56A5 9079 C068  94BD 63BC 1CFE 91D3 06C6
          # uid                  Swift 3.x Release Signing Key <[email protected]>
              A3BAFD3556A59079C06894BD63BC1CFE91D306C6 \
          # pub   4096R/71E1B235 2016-05-31 [expires: 2019-06-14]
          #       Key fingerprint = 5E4D F843 FB06 5D7F 7E24  FBA2 EF54 30F0 71E1 B235
          # uid                  Swift 4.x Release Signing Key <[email protected]>
              5E4DF843FB065D7F7E24FBA2EF5430F071E1B235 \
            ; do \
              gpg --quiet --keyserver ha.pool.sks-keyservers.net --recv-keys "$key"; \
            done \
        && gpg --batch --verify --quiet swift.tar.gz.sig swift.tar.gz \
        && tar -xzf swift.tar.gz --directory / --strip-components=1 \
        && rm -r "$GNUPGHOME" swift.tar.gz.sig swift.tar.gz \
        && chmod -R o+r /usr/lib/swift

    # Post cleanup for binaries orthogonal to swift runtime, but was used to download and install.
    RUN apt-get -y remove --purge \
        python2.7

    # Post cleanup for binaries orthogonal to swift runtime, but was used to download and install.
    RUN apt-get -y remove --purge \
        python2.7

    # Print Installed Swift Version
    RUN swift --version

# Install our Swift Server
ADD . /Addaapi-Perfect
WORKDIR /Addaapi-Perfect

RUN swift build

# Build release version
RUN swift build --configuration release```

my error http://prntscr.com/gs7b6r

Hello!

I have an application that uses the Accelerate Framework and I'm wondering if there is a way to use it inside this Docker image? I'm aware that some stuff isn't ported over but information about package management etc isn't easy to find for Swift on Docker.

Thanks!

Less duplication, it seems. cf. https://github.com/OliverLetterer/swift-docker/blob/master/Dockerfile

These are required as an official image, and currently exist out of tree, for example: https://github.com/docker-library/official-images/tree/master/test/tests/swift-hello-world

We should bring this into this repo, and have CI check them.

We should also add a test for the timezone support as evidenced by #98.

Can we get a tag for the official Swift 3.0 release on Dockerhub?

Background

About a year ago Mario from Docker contacted us asking if we would consider bringing this into the official images. The community said yes, but Haris and I both got very busy. I'm now working on Swift backend development full time and this is squarely under my remit.

Why

• Promote adoption of Swift on Docker, and Swift
• Get free security scanning from Docker Hub
• Get support from Docker engineers on best practice engineering of Dockerfile

How

We need to prepare two pull requests:

1. A documentation pull request against the docs repo, essentially a Markdown file that is the contents of the description on Docker hub (for instance, https://hub.docker.com/_/mongo/)
2. A descriptive pull request against the library repo specifying the available tags and versions for docker hub.

Todo

• Mario is apparently no longer with Docker. We should find a counterpart who's willing to champion this inside Docker
• Draft a documentation PR in this repo
• Draft an image PR in this repo Fuck it ship it

The slim compiler image doesn't need full Ubuntu if we can get away with it.

To try:

• busybox
• other slim Debian images?
• ??

The base image MUST be an official Docker image.

It seems that swiftdocker/swift:latest is still pointing to 4.0.2. I expected it to be pointing to 4.0.3.

Thanks!

I have a problem that this image whether or not to support arm64 architecture.

Hey, thanks for putting together this docker image for swift!
I just added it to BitRun, a small project for coding sandboxes that im running. Works great.
Try it yourself - https://bit.run/try/swift

Currently every new release requires manual generation of new Dockerfiles and images.

Continuous integration using Travis CI, the RSS feed from the releases page and the nightly snapshots would allow this to happen.

Anybody want to take this on?

https://hub.docker.com/r/_/swift/ states:

docker run --cap-add sys_ptrace -it --rm swift swift

However, this doesn't actually work. You need --privileged

Also,

docker run  -it --name swiftfun swift:latest /bin/bash

Seems like it should be written as:

docker run  --privileged -it --name swiftfun swift:latest

Removing /bin/bash and adding --privileged.

(It wasn't clear to me if the page can be updated via changes to the repo.)

I tried to get this to run:

docker pull swiftdocker/swift
docker run -i -t --name swiftfun swiftdocker/swift:latest /bin/bash

Then if I run swift, I get the following error:

/usr/bin/lldb: error while loading shared libraries: libxml2.so.2: cannot open shared object file: No such file or directory

Is this a known error? If not, I'll try to find the cause.

When running as a regular user, swiftc can't compile some code because the files in /usr/lib/swift/CoreFoundation are not readable:

swift@50cd436932d2:~$ ls -la /usr/lib/swift/CoreFoundation/|head
total 1108
drwxr-xr-x 2 root root  4096 Mar 28 07:02 .
drwxr-xr-x 9 root root  4096 Mar 28 07:02 ..
-rw-r----- 1 root root 31568 Mar 28 07:02 CFArray.h
-rw-r----- 1 root root   788 Mar 28 07:02 CFAsmMacros.h
-rw-r----- 1 root root 11948 Mar 28 07:02 CFAttributedString.h

That issue seems to be specific to CoreFoundation, the other directories seem to come with proper permissions.

Using the instructions found in #9 I have successfully run a REPL, but when trying to import Foundation, I get the following error:

$ docker run --cap-add sys_ptrace --privileged -it --rm swiftdocker/swift swift
Welcome to Swift version 4.0 (swift-4.0-RELEASE). Type :help for assistance.
  1> import Foundation
/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:10: note: while building module 'SwiftGlibc' imported from /usr/lib/swift/CoreFoundation/CoreFoundation.h:25:
#include <sys/types.h>
         ^

<module-includes>:3:10: note: in file included from <module-includes>:3:
#include "///usr/include/utmp.h"
         ^

///usr/include/utmp.h:23:10: note: in file included from ///usr/include/utmp.h:23:
#include <sys/types.h>
         ^

error: /usr/include/x86_64-linux-gnu/sys/types.h:146:10: error: 'stddef.h' file not found
#include <stddef.h>
         ^

<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "CoreFoundation.h"
         ^

error: /usr/lib/swift/CoreFoundation/CoreFoundation.h:25:10: error: could not build module 'SwiftGlibc'
#include <sys/types.h>
         ^

/usr/lib/swift/CoreFoundation/CFStream.h:20:10: note: while building module 'CDispatch' imported from /usr/lib/swift/CoreFoundation/CFStream.h:20:
#include <dispatch/dispatch.h>
         ^

<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "dispatch.h"
         ^

/usr/lib/swift/dispatch/dispatch.h:30:10: note: in file included from /usr/lib/swift/dispatch/dispatch.h:30:
#include <os/linux_base.h>
         ^

/usr/lib/swift/os/linux_base.h:17:10: note: in file included from /usr/lib/swift/os/linux_base.h:17:
#include <sys/sysmacros.h>
         ^

error: /usr/include/x86_64-linux-gnu/sys/sysmacros.h:22:10: error: could not build module 'SwiftGlibc'
#include <features.h>
         ^

error: could not build C module 'CoreFoundation'

Is this expected? Should I be able to import Foundation, or am I required to create a separate image and install Foundation there?

What are image flavors?

Image flavors are variants of the image that offer different environments. While the main, default flavor is the one that supports 80-90% of use cases, we should be able to offer variants that support other use cases to minimize the amount of customization a user needs.

What's this issue for?

This issue tracks the effort to expand beyond the current default flavor into three new flavors:

• default flavor will gain more pre-installed dependencies to make quick hacking faster and easier.
• slim flavor that can minimally compile a Swift program and do little else.
• runtime flavor that has the bare library support for the Swift standard library and Foundation.

Read on for the rationale.

Related milestones:

1. slim-compiler
2. slim-runtime

Why do we need image flavors?

There are two kinds of users of docker-swift, in my opinion:

1. Power/production users who deploy containerized workloads written in Swift

These users want customizable, small containers. The image is big enough as it is and it's frankly embarrassing how slow it is to deploy a Swift workload vs a Go workload into a container orchestrator. They do not want openssl or vim unless they install it themselves.

To address their needs we should offer:

• support for multi stage builds, providing a minimal image with a compiler and nothing* else.
• either:
  • documentation for complete static linking of all dependencies (including standard library, libxml, libicu, libcurl, and whatever else Foundation needs) OR
  • documentation for building a static-ish executable AND a runtime image that contains the stdlib and Foundation dependencies

2. "Make it easy for me" users who really want more of a glorified VM

These users want a shell, the Ubuntu environment, and the common external dependencies used by many of the projects currently around (mainly HTTP servers). The VAST MAJORITY of our user base are Mac-based Swift devs who want to test their code locally under Linux, and in some cases aren't even deploying a containerized app. This is what the default image mostly does already, but we have room to expand it.

I.e. explain how this works, which is what I'm currently doing:

sed -e 's/v\$SWIFT_VERSION/swift-3.1.1-RELEASE/' -e 's/v\$SWIFT_BRANCH/swift-3.1.1-release/' Dockerfile.template > 3.1/Dockerfile

Since there aren't many of us, Swift is improving rapidly and I don't hear millions of voices crying out for it, I executively resolve that:

1. This project will only support the latest two major version numbers of Swift
2. This project will only support the latest minor version of the previous major version of Swift
3. This project will only support the latest two minor versions of the latest major version of Swift
4. This project will only support the latest patch version of any major version.

Furthermore:

Only supported versions will be available under the official image on Docker hub.

If you want older versions, you can get them from our unofficial automated build repo. If you want to support more, you'll need to give us a hand.

To make these rules clear, I am highlighting in bold the supported versions:

Swift 4.0.2
Swift 4.0
Swift 3.1.1
Swift 3.1
Swift 3.0.2
Swift 3.0.1
Swift 3.0
Swift 2.2.1
Swift 2.2.

Add this to your Dockerfile to remove the offending code that causes the 3.1 image to fail.
RUN sed -i '/#include <Block.h>/d' /usr/lib/swift/CoreFoundation/CFBase.h

Tracking the issue in apple/swift-corelibs-foundation#843

I believe snapshot version should be DEVELOPMENT-SNAPSHOT-2016-09-06-a rather DEVELOPMENT-SNAPSHOT-2016-09-02-a. Please advise.

Any plans to include development snapshots like Swift 4.1 Development ?

This would be very helpful in running tests against future versions.

If we can get an RSS feed or something of new snapshots, we can auto push new snapshots for access to preview versions of Swift.

Running latest master is still broken @swizzlr

gpg: no valid OpenPGP data found.
gpg: the signature could not be verified.
Please remember that the signature file (.sig or .asc)
should be the first file given on the command line.
gpg: no valid OpenPGP data found.
gpg: the signature could not be verified.
Please remember that the signature file (.sig or .asc)
should be the first file given on the command line.

You should run 'apt-get clean' at the end of the apt-get installation process; this will remove any downloaded .tgz files which are no longer needed from /var/cache/apt

My commits appear twice after the last merge.

cf. docker-library/python#77

Perhaps this could work?

ONBUILD COPY Package.swift /code/
ONBUILD RUN swift build -c release # cache dependency build artefacts
ONBUILD COPY Sources /code/
ONBUILD RUN swift build -c release # specify destination for output binary
CMD # predefined output binary

I'm unable to type or paste from clipboard Unicode characters like £ (via option 3 on OSX) or ≈ (option x) inside the Swift 3 repl running in Docker. I noticed that by default I can't type these characters into a bash shell inside this container at all unless adding the environment variable -e "LANG=C.UTF-8", which apparently is related to the base ubuntu image. However, even with that env var provided and working in bash, the unicode characters still won't appear in the Swift repl.

Some basic versions (can provide more detail as needed):

$ docker-machine version
docker-machine version 0.6.0, build e27fb87

$ docker -v
Docker version 1.10.3, build 20f81dd

Command to start bash / Swift repl:

$ docker run -it --rm --privileged=true -e "LANG=C.UTF-8" swiftdocker/swift [bash|swift]

I have no trouble typing these characters into a Swift 2.2 repl running locally, installed via Homebrew

I know a few people who have done this. Will ask.

We should find a way of installing Swift and removing LLDB and the REPL.

docker-compose.yml

version: '3'

services:
  server:
    image: swift:3.0
    volumes:
      - ./:/files/
    ports:
      - 80:80
    restart: always

$ docker-compose up
Creating mydirectory_server_1
Attaching to mydirectory_server_1
mydirectory_server_1 exited with code 0

$ docker-compose ps
      Name          Command      State      Ports 
-------------------------------------------------
mydirectory_server_1   /bin/bash   Restarting 

Pretty confusing... Why is it stuck restarting?

The default docker-swift flavor should have the batteries included to get most common Swift projects off the ground fast.

To add:

• openssl
• libuuid
• ?

Related to #90. Supersedes #73.

Please add suggestions as necessary.

Why not using latest ubuntu version? It's 15.10 already

Can we make an image that works on this instead? Do we need to recompile a custom flavour of swift that'll work on a non-debian distribution?

We're pinning to 3.6 right now, should it be 3.8 or even 4.0? Let's check in with CI and dev team.

Hello! New to docker so I am still trying to get my head around things. Looks really great but sorry in advance if I have something wrong here.

https://hub.docker.com/_/swift/ mentions it being "A great way to try out pre-release builds!" which makes me believe Swift 4 is in scope for this project.

What needs to take place for this to happen. Is it just a matter of making a Dockerfile with the appropriate branch and checksum? If that is something I worked on, is it a patch you would accept? Let me know what you think.

Version 3.0.2 works but latest (3.1) does not.

System is Windows 10
PS C:\> docker version
Client:
 Version:      17.03.1-ce
 API version:  1.27
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Tue Mar 28 00:40:02 2017
 OS/Arch:      windows/amd64

Server:
 Version:      17.03.1-ce
 API version:  1.27 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Fri Mar 24 00:00:50 2017
 OS/Arch:      linux/amd64
 Experimental: true

How to reproduce:

$ docker run --privileged=true --rm -it swift:3.0.2 swift
Welcome to Swift version 3.0.2 (swift-3.0.2-RELEASE). Type :help for assistance.
  1> import Glibc
  2> random()
$R0: Int = 1804289383

$ docker run --privileged=true --rm -it swift:latest swift
Welcome to Swift version 3.1 (swift-3.1-RELEASE). Type :help for assistance.
  1> import Glibc
:3:10: note: in file included from :3:
#include "///usr/include/utmp.h"
         ^
 
///usr/include/utmp.h:23:10: note: in file included from ///usr/include/utmp.h:23:
#include 
         ^
 
error: /usr/include/x86_64-linux-gnu/sys/types.h:146:10: error: 'stddef.h' file not found
#include 
         ^
 
error: could not build Objective-C module 'SwiftGlibc'

I'm trying to compile my project on the swift:4.0.2 image and get the following errors:

Notice the git version at the end is 2.7.4, the newest one as of now is 2.15.x, I don't know if that's the issue.

# swift build -c release --static-swift-stdlib
Fetching https://github.com/vapor/vapor.git
Fetching https://github.com/vapor/leaf-provider.git
Fetching https://github.com/vapor/core.git
Fetching https://github.com/vapor/debugging.git
Fetching https://github.com/vapor/leaf.git
Fetching https://github.com/vapor/random.git
Fetching https://github.com/vapor/sockets.git
Fetching https://github.com/vapor/bcrypt.git
Fetching https://github.com/vapor/bits.git
Fetching https://github.com/vapor/console.git
Fetching https://github.com/vapor/node.git
Fetching https://github.com/vapor/tls.git
error: failed to clone; Cloning into bare repository '/Source/.build/repositories/vapor.git--3231922947425880948'...
fatal: unable to access 'https://github.com/vapor/vapor.git/': Could not resolve host: github.com
error: product dependency 'Vapor' not found
error: product dependency 'LeafProvider' not found
error: product dependency 'Testing' not found
# git --version
git version 2.7.4

Package.swift

// swift-tools-version:4.0

import PackageDescription

let package = Package(
    name: "my_project",
    products: [
        .library(name: "App", targets: ["App"]),
        .executable(name: "Run", targets: ["Run"])
    ],
    dependencies: [
        .package(url: "https://github.com/vapor/vapor.git", .upToNextMajor(from: "2.2.0")),
        .package(url: "https://github.com/vapor/leaf-provider.git", .upToNextMajor(from: "1.1.0")),
    ],
    targets: [
        .target(name: "App", dependencies: ["Vapor", "LeafProvider"],
               exclude: [
                   "Config",
                   "Database",
                   "Public",
                   "Resources"
               ]),
        .target(name: "Run", dependencies: ["App"]),
        .testTarget(name: "AppTests", dependencies: ["App", "Testing"])
    ]
)

Master's received a number of improvements since 3.1 came out. We should back port these and then PR them into official-images.