为什么部署到K8s时找不到bash文件？

Question

我有一个 dockerfile 和一个自定义 SQL 服务器 2019 安装运行一个 bashscript，这反过来又调用另一个 bash 脚本：

FROM mcr.microsoft.com/mssql/server:2019-CU8-ubuntu-16.04 
ARG BuildConfiguration=Debug

USER root
# Install Unzip
RUN apt-get update \
    && apt-get install unzip -y

# Install SQLPackage for Linux and make it executable
RUN wget -progress=bar:force -q -O sqlpackage.zip https://go.microsoft.com/fwlink/?linkid=2143497 \
    && unzip -qq sqlpackage.zip -d /opt/sqlpackage \
    && chmod +x /opt/sqlpackage/sqlpackage

USER mssql

# Create a config directory
RUN mkdir -p /usr/config
WORKDIR /usr/config

# Copy required source files
COPY entrypoint.sh /usr/config
COPY configure-db.sh /usr/config
COPY setup.sql /usr/config
COPY PrepareServer.sql /usr/config
COPY tSQLt.class.sql /usr/config
# Copy the dacpac, that we will be deploying. Make sure the project has built before you run the dockerfile!
COPY ./bin/${BuildConfiguration}/Database.dacpac /usr/config

ENTRYPOINT ["/bin/bash", "./entrypoint.sh"]

CMD ["tail -f /dev/null"]

HEALTHCHECK --interval=15s CMD /opt/mssql-tools/bin/sqlcmd -U sa -P $MSSQL_SA_PASSWORD -Q "select 1" && grep -q "MSSQL CONFIG COMPLETE" ./config.log

入口点.sh：

#!/bin/bash

/opt/mssql/bin/sqlservr &

/bin/bash /usr/config/configure-db.sh

eval $1

配置-db.sh：

#!/bin/bash
# wait for MSSQL server to start
export STATUS=1
i=0

while [[ $STATUS -ne 0 ]] && [[ $i -lt 30 ]]; do
    i=$i+1
    /opt/mssql-tools/bin/sqlcmd -t 1 -U sa -P $MSSQL_SA_PASSWORD -Q "select 1" >> /dev/null
    STATUS=$?
done

if [ $STATUS -ne 0 ]; then 
    echo "Error: MSSQL SERVER took more than thirty seconds to start up."
    exit 1
fi

echo "======= MSSQL SERVER STARTED ========"
# Run the setup script to create the DB and the schema in the DB
/opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P $MSSQL_SA_PASSWORD -d master -i setup.sql
#install the tSQLt CLR for testing
echo "======= PREPARING FOR tSQLt ========"
/opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P $MSSQL_SA_PASSWORD -d master -i PrepareServer.sql
echo "======= PREPARATION FOR tSQLt FINISHED ========"
echo "======= INSTALLING tSQLt ========"
/opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P $MSSQL_SA_PASSWORD -d master -i tSQLt.class.sql
echo "======= INSTALLING tSQLt FINISHED========"

echo "======= Starting Deployment of Dacpac ========"
/opt/sqlpackage/sqlpackage /a:Publish /tsn:. /tdn:${MSSQL_DB} /tu:sa /tp:$MSSQL_SA_PASSWORD /sf:/usr/config/Database.dacpac

echo "======= Finished Deployment of Dacpac ========"
echo "======= MSSQL CONFIG COMPLETE ======="

然后将其部署到 Kuberenetes，但在启动时我在日志中看到以下行：

./entrypoint.sh: line 2: $'\r': command not found
./entrypoint.sh: line 3: $'\r': command not found
./entrypoint.sh: line 4: $'\r': command not found
: No such file or directoryigure-db.sh
./entrypoint.sh: line 6: $'\r': command not found

我在 Notepad++ 和 VSC 中搜索了回车，但没有找到。 记事本以及 VSC 显示，EOL 设置为 Unix (LF)

我尝试在 pod 内手动运行带有 bash 的文件 configure-db.sh 并收到以下 output：

mssql@sql-dev:/usr/config$ /bin/bash configure-db.sh 
configure-db.sh: line 5: $'\r': command not found
configure-db.sh: line 33: syntax error: unexpected end of file

奇怪的是，使用 docker-compose 运行它可以完美运行。 我在这里做错了什么吗？

更新只是为了确保，我没有意外忽略任何事情，我继续前进，并打开了 WSL / Ubuntu 上的解决方案文件夹，并使用sudo chown +x./entrypoint2.sh创建了一个 entrypoint2.sh 并在 dockerfile 中引用了它。 我确定行尾确实是 LF / \n而不是CR-LF，然后签入文件并部署它。 此外，我再次通过dos2unix运行该文件。

结果是一样的。 它使用 docker-compose 工作，但使用 Kubernetes 会引发错误：

./entrypoint2.sh: line 2: $'\r': command not found
./entrypoint2.sh: line 4: $'\r': command not found
./entrypoint2.sh: line 5: $'\r': command not found
: No such file or directoryusr/config/configure-db.sh
./entrypoint2.sh: line 7: $'\r': command not found

Answer 1

错误不是没有找到bash，而是没有找到\r 。 这表明您已经使用 Windows 换行符保存了您的脚本，并尝试在 Linux 平台上运行该脚本。 在您的编辑器中，使用 Linux 换行符（LF，而不是 CR-LF）保存脚本。 或者您可以使用 dos2unix 之类的工具从脚本中删除回车符。

Answer 2

我已经尝试在

• Windows 10
• Ubuntu 20.04

在这两种情况下，他们都很好。 所以我排除了这种可能性，它是在开发机器上安装错误配置的 git。

这让我只剩下我们的 CI/CD 管道作为可能的罪犯。 所以我创建了一个包含以下内容的.gitattributes文件：

*.sh text eol=lf

这解决了这个问题。 现在正在检查并正确复制这些文件。 运行时不再出现错误。

作为替代方案，总是有可能在 K8s 上创建一个 initContainer 来安装 dos2unix 并在那里修复文件，但这感觉不那么优雅，更像是使用核武器来猎兔。

非常感谢 BMitch 给了我检查容器内文件的建议，而不仅仅是在源代码上。