Container is not at all a new technology these days within global software community. There has been a time when people were discussing a lot about containers and its future applications. But it is not the case now as they are an integral part of modern hybrid cloud infrastructure. The core of this article may not be on containers and related technologies rather a report on my learning curve as a newbie in bringing Samba in to containers. Samba? Yes, it is a free software implementation of SMB protocol providing file and print services capable of integrating with Windows server domain as a Domain Controller or as a domain member. You can grab more details from Samba project page. Last but not the least, readers are expected to have basic knowledge on containers, Dockerfile etc as explaining those are not my intention here in this article.

I take this opportunity to introduce few projects aimed at integrating Samba in to Kubernetes world. Yes, you heard it right. As you might already know Kubernetes clusters contain pods and pods are just collection of containers. Overall initiative is termed as SinK which is said to be an abbreviation for Samba-in-Kubernetes. As a result we have the following two initial project repositories:

• sambacc
• samba-container

sambacc is a python based tool to help with Samba configuration when running inside containers. It is designed in such a way that it tries to automate many manual steps required in setting up smbd, the main Samba daemon, and others. When installed it provides a binary named samba-container along with core sambacc library. We can also find a Dockerfile inside the repository which basically builds a sambacc container out of Fedora container image. The built container includes just a build script to perform the installation of samba-container binary and sambacc library when it is normally run using command line utilities for container management like docker, podman etc. We also have sambacc container built(and tagged latest) nightly and pushed to Quay container registry for easier access under samba.org/sambacc. This workflow is implemented using GitHub actions within same sambacc repository.

samba-container repository maintains sources for building container images for Samba services. Apart from file/member server configurations we have image for running Samba in AD DC(Active Directory Domain Controller) role. Thinking from testing perspective we also have a basic Samba client container image with smbclient(using libsmbclient) utility present by default. Looking at how basic server image is built, we see a multi-stage build process i.e, we make use of contents from a particular image(in this case it is sambacc) thereby including those in the server image finally built. In this context it allows samba-container image to be built out of specific version of sambacc in an efficient and convenient manner.

FROM quay.io/samba.org/sambacc:latest AS builder
ARG SAMBACC_VER=fd747527ed86d01821c4a3b72f1c4f893bb1ca36
ARG SAMBACC_REPO=https://github.com/samba-in-kubernetes/sambacc

RUN /usr/local/bin/build.sh ${SAMBACC_VER} ${SAMBACC_REPO}

FROM registry.fedoraproject.org/fedora:34

MAINTAINER John Mulligan <jmulligan@redhat.com>
ENV SAMBACC_VERSION="0.1"

COPY smb.conf /etc/samba/smb.conf
RUN dnf install --setopt=install_weak_deps=False -y \
    findutils \
    python-pip \
    python3-jsonschema \
    python3-samba \
    samba \
    samba-client \
    samba-winbind \
    samba-winbind-clients \
    tdb-tools \
    ctdb \
    && dnf clean all \
    && cp --preserve=all /etc/ctdb/functions /usr/share/ctdb/functions \
    && cp --preserve=all /etc/ctdb/notify.sh /usr/share/ctdb/notify.sh \
    && true

COPY --from=builder \
    /var/tmp/build/sambacc/dist/sambacc-$SAMBACC_VERSION-py3-none-any.whl \
    /tmp/sambacc-$SAMBACC_VERSION-py3-none-any.whl
RUN pip install /tmp/sambacc-$SAMBACC_VERSION-py3-none-any.whl \
    && rm -f /tmp/sambacc-$SAMBACC_VERSION-py3-none-any.whl \
    && ln -s /usr/local/share/sambacc/examples/minimal.json /etc/samba/container.json \
    && true

VOLUME ["/share"]

EXPOSE 445

ENV SAMBACC_CONFIG="/etc/samba/container.json:/etc/samba/users.json"
ENV SAMBA_CONTAINER_ID="demo"
ENTRYPOINT ["samba-container"]
CMD ["run", "smbd"]

Similar to what we have with sambacc images, nightly jobs are setup to push samba-container and samba-ad-container images built out of latest Samba upstream code base and are made available on samba.org/samba-container repository. This is possible with the help of RPMs that are built out of Samba master branch and made available for Fedora and CentOS via CentOS CI infrastructure as YUM repository. We do maintain separate samba-integration repository for daily Samba build process. For more details refer samba-build branch from samba-integration GitHub repository.

---

That’s mostly on how Samba is containerized using Docker containers. But is that it? No, there’s more into it. As I mentioned earlier these containers are integral part of Kubernetes which is basically a container orchestration software suite. Next step is to deploy those containerized applications with the help Kubernetes API. Here comes the importance of an operator. Kubernetes operator is intended to automate the method of packaging, deploying and managing an application in a cluster. And when it comes to Samba we also do require a custom operator. samba-operator is another project aimed at developing an operator for Kubernetes in this context. I am not attempting to get into more details on samba-operator here as it is out of scope for this article(and I don’t have enough knowledge yet!). I hope I come back with another article on how samba-operator is designed after gaining more expertise in Kubernetes and operators. Till then, happy hacking !