#dockercompose

Introduction

Deploying Microsoft SQL Server can sometimes be a daunting task, especially for developers who just want to set up a quick and simple instance for testing or small-scale use. Docker Compose offers a straightforward solution to this problem, allowing you to define and run multi-container Docker applications with ease. In this blog post, we’ll walk through creating a docker-compose.yml file to deploy SQL Server efficiently.

Prerequisites

Before we begin, ensure you have Docker and Docker Compose installed on your system. If not, you can download and install them from the official Docker website.

Crafting the Docker Compose File

Below is a sample docker-compose.yml file designed to run Microsoft SQL Server in a Docker container:

Understanding the Configuration

Let’s break down the components of this configuration file:

version: This specifies the version of Docker Compose to use, which in this case is 3.8.

services: Under this key, we define all the services (containers) we want to run.

sql-server-db: This is the name of our service.

image: This key specifies the Docker image to use. We’re using the latest version of SQL Server 2019.

container_name: We define a custom name for our container for easier reference.

environment: Here, we set necessary environment variables.

SA_PASSWORD: The password for the sa user. Ensure to replace "YourStrong!Passw0rd" with a strong, unique password.

ACCEPT_EULA: This is mandatory and must be set to Y to run SQL Server in a container.

ports: We map port 1433 on the host to port 1433 in the container, which is the default for SQL Server.

volumes: This is crucial for data persistence. We define a volume named sql-server-data mounted at /var/opt/mssql in the container.

volumes: We declare the named volume sql-server-data for use in our service.

Deploying SQL Server with Docker Compose

With the docker-compose.yml file in place, navigate to its directory in the terminal and run the command:

docker-compose up -d

This command will download the specified SQL Server image (if not already downloaded), create a container with the specified settings, and start it in detached mode.

Connecting to SQL Server

Once the container is running, you can connect to the SQL Server instance using any SQL Server client, with the server address as localhost,1433 and the sa user credentials you specified in the docker-compose.yml file.

Conclusion

Докер еще с версии 17.05 поддерживает Multi-Stage сборку. Не знаю, возможно это мне так везет, но все что удалось почитать на эту тему сводится к сборке максимально минималистичного Golang образа.

Выглядит это примерно так (взял практически из официальной документации):

FROM golang:latest AS builder WORKDIR ./src COPY . . RUN go build ./src/main.go FROM alpine:latest COPY --from=builder /go/main . CMD ["./main"]

При сборке этого образа происходит дословно следующее. Первый блок FROM под названием builder собирает (компилирует) наше Go приложение. Второй блок FROM берет голый alpine образ и вставляет в него артефакт из первого блока (под артефактом подразумевается скомпилированный бинарник).

Если мы выполним нижеследующую команду, то мы действительно, и по понятным причинам получим минимальный из возможных образ.

$ docker build -t ./go-docker:latest .

И здесь начинается самое интересное. Уменьшив размер образа мы удалили из него практически все, в том и числе, и все что связано с компиляцией. Но ведь мы уже привыкли использовать докеры не только в продакшене, но и в девелоп процессах и возможность компиляции для нас критически важна. Так как же совместить эти заведомо противоречие требования? Как по мне, так это и есть основная причина использования Multi-Stage сборок, а отнюдь не размер образа.

В первую очередь Multi-Stage сборка это когда мы можем использовать один и тот же докер файл в массе сценариев. В нашем случае нам просто достаточно добавить в docker-compose один параметр и мы решаем проблему.

version: "3.4" services: go-builder: build: context: . dockerfile: ./Dockerfile target: builder container_name: go-builder

Параметр target: builder говорит нам,что нам необходимо использовать в докере именованный блок builder. И это простое действие позволяет нам ничего не менять в нашем процессе разработки. Все наши компиляторы на месте, но при этом в продакшене наш образ максимально минимизирован. Одни плюсы.

Для наглядности в наш докер файл можно добавить еще один слой. И в разработке уже использовать блок develop.

FROM golang:latest AS develop WORKDIR ./src COPY . . FROM develop AS builder RUN go build ./src/main.go FROM alpine:latest COPY --from=builder /go/main . CMD ["./main"]

Golang это компилируемый язык, а будет ли польза от использования Multi-Stage в интерпретируемых языках. Ведь интерпретатор в них должен присутствовать в любом случае, хоть в девелоп окружении, хоть в продакшене. И ответ, да.

Для примера возьмем Python и у нас имеется две среды: develop и production. А также в наличии три файла requirements. В первом (requirements.txt) содержатся пакеты необходимые для всех используемых сред (например Django). Во втором (requirements.dev.txt) содержатся пакеты необходимые нам в процессе разработки (например coverage). А в третьем (requirements.prod.txt) пакеты необходимые для развертывания приложения (например gunicorn). В данном примере наш docker файл примет примерно такой вид:

FROM python:3.7 AS stage WORKDIR /opt/app ADD requirements.txt /opt/app/ RUN pip install --no-cache-dir -r /opt/app/requirements.txt FROM stage AS develop ADD requirements.dev.txt /opt/app/ RUN pip install --no-cache-dir -r /opt/app/requirements.dev.txt FROM stage AS production ADD requirements.prod.txt /opt/app/ RUN pip install --no-cache-dir -r /opt/app/requirements.prod.txt

Думаю, из контекста все понятно. Но есть один вопрос. Как нам собрать образ для продакшена, ведь в нашем случае туда попадут все три блока, а нам бы хотелось иметь только один production. И в этом нам поможет уже знакомый по docker-compose параметр target. Только этот раз мы его используем уже непосредственно при сборке docker файла.

$ docker build — target production -t ./python-docker:latest .

Há tempos que eu procuro um método de criar e recriar um ambiente de desenvolvimento com certa facilidade, até que encontrei o Docker Compose.

Com ele eu consigo com apenas um comando: instalar dependencias, instalar aplicações dependendes, criar banco de dados, e tudo o que mais for necessário

Mas indo por partes, o que é o Docker?

Basicamente, é uma maneira padronizar a forma na qual você entrega sua aplicação, por meio de um arquivo (Dockerfile) com as instruções de build e packing do seu sistema. Você pode criar imagens das suas aplicações e executá-las dentro de containeres virtualizados, tendo controle sob tudo o que acontece.

Link para instalção do Docker e o Compose: https://docs.docker.com/compose/install/

Portanto, o Docker Compose é uma aplicação que ajuda no gerenciamento desses containers e imagens, e com ele torna-se mais fácil o gerenciamento de aplicações complexas. Ok, mas como?

O Compose utiliza um arquivo (docker-compose.yml) com as instruções para a criação dos containeres, vejamos um exemplo abaixo para um ambiente de desenvolvimento Rails:

https://gist.github.com/alvarocantador/6612d710136cae93f8d175d2a9eb6eae

Neste arquivo estou criando containeres para:

O PostgreSQL, que é o banco de dados que prefiro utilizar. Aqui utlizo uma imagem já pronta, sendo essa https://hub.docker.com/_/postgres/. Se preferir utilizar outro banco de dados você pode procurar a imagem no Docker Hub

O Elasticsearch, onde utilizo para busca textual. Repare que nele libero as portas 9200 e 9300 para o acesso da aplicação.

E por fim, a aplicação Rails. Ele tem seu próprio Dockerfile, o qual deve ficar na raiz da aplicação.

O Dockerfile:

https://gist.github.com/alvarocantador/ecf3c126c4f8b1a98b698b8ef85f86ab

Basicamente é isso, basta colocar ambos os arquivos e executar o comando "docker-compose up"