Tag: EDI

EDI or Electronic Data Interchange is a computer-to-computer exchange of business documents between companies in a standard electronic format. Even though EDI has been around since 1960s and there are alternatives such as API, EDI still remains a crucial business component in industries such as supply chain and logistics.

With EDI, there is no longer a need to manually enter data into the system or send paper documents through the mail. EDI replaces the traditional paper-based communication, which is often slow, error-prone, and inefficient.

EDI works by converting business documents into a standard electronic format that can be exchanged between different computer systems. The documents later can be transmitted securely over a network using a variety of protocols, such as SFTP. Upon receipt, the documents are automatically processed and integrated into the computer system of the recipient.

EDI and SFTP

There are many EDI software applications using SFTP as one of the methods for transmitting EDI files between two systems. This allows the EDI software to create EDI files, translate them into the appropriate format, and then transmit them securely via SFTP.

SFTP provides a secure and reliable method for transmitting EDI files between trading partners. It uses a combination of SSH (Secure Shell) encryption and SFTP protocol for secure file transfer. This helps to ensure that EDI files are transmitted securely and that sensitive business data is protected from unauthorized access.

In this blog post, we will take a look at how to setup simple SFTP on Kubernetes.

Setup SFTP Server Locally with Docker

On our local machine, we can also setup SFTP server on Docker with an image known as “atmoz/sftp”, which offers easy-to-use SFTP server with OpenSSH.

When we run it on our Docker locally, we can also mount it with our local directory with the command below.

docker run \
    --name my_sftp_server \
    -v C:\Users\gclin\Documents\atmoz-sftp:/home/user1/ftp-file-storage \
    -p 2224:22
    -d atmoz/sftp:alpine \
    user1:$6$Zax4...Me3Px/:e:::ftp-file-storage

This allows the user “user1” to login to this SFTP server with the encrypted password “$6$Zax4…Me3Px” (The “:e” means the password is encrypted. Here we are using SHA512).

The directory name at the end of the command, i.e. “ftp-file-storage”, will be created under the user’s home directory with write permission. This allows the files uploaded by the user to be stored at the “ftp-file-storage” folder. Hence, we choose to mount it to our local Documents sub-directory “atmoz-sftp”.

The OpenSSH server runs by default on port 22. Here, we are forwarding the port 22 of the container to the host port 2224.

Currently, this Docker image provides two versions, i.e. Debian and Alpine. According to the official documentation, Alpine is 10 times smaller than Debian but Debian is generally considered more stable and only bug fixes as well as security fixes are added after each Debian release which is about 2 years.

Moving to Kubernetes

Setting up SFTP on Kubernetes can be done using a Deployment object with a container running the SFTP server.

Firstly, we will use back the same image “atmoz/sftp” for our container. We will then create a Kubernetes Deployment object using a YAML file which defines a container specification including the SFTP server image, environment variables, and volume mounts for data storage;

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sftp-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sftp
  template:
    metadata:
      labels:
        app: sftp
    spec:
      volumes:
      - name: sftp-data
        emptyDir: {}
      containers:
      - name: sftp
        image: atmoz/sftp
        ports:
        - containerPort: 22
        env:
        - name: SFTP_USERS
          value: "user1:$6$NsJ2.N...DTb1:e:::ftp-file-storage"
        volumeMounts:
        - name: sftp-data
          mountPath: /home/user1/ftp-file-storage
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"

To keep things simple, I mounted emptyDir to the Container. The emptyDir is basically a volume first created and initially empty when a Pod is assigned to a Node, and exists as long as that Pod is running on that Node.

In addition, in order to avoid our container to starve other processes, we will add resource limits to it. In the YAML definition above, our container will be defined with a request for 0.25 CPU and 64MiB of memory. Also, the container has a limit of 0.5 CPU and 128MiB of memory.

Next, since I will be doing testing locally on my machine, I will be using the kubectl port-forward command.

kubectl port-forward deploy/sftp-deployment 22:22

After doing all these, we can now access the SFTP server on our Kubernetes cluster as shown in the following screenshot.

Conclusion

Yup, that’s all for having a SFTP server running on our Kubernetes easily.

After we have configured our SFTP server to use secure authentication and encryption, we can then proceed to create an SFTP user account on the server and give each of the parties who are going to communicate with us using EDI the necessary permissions to access the directories where EDI files will be stored.

Finally, we also need to monitor file transfers for errors or issues and troubleshoot as needed. This may involve checking SFTP server logs, EDI software logs, or network connections.

Overall, this is the quick start of using SFTP for EDI to ensure the secure and reliable transfer of electronic business documents between different parties.