Giter VIP home page Giter VIP logo

docker-sdk's Introduction

Spryker Commerce OS — Docker SDK

Build Status

Description

Spryker Docker SDK helps to set up a Docker environment for your Spryker project.

This repository does not contain a specific Dockerfile or Docker Compose files. It contains a tool that prepares those files to match the infrastructure of your Spryker project.

Spryker Docker SDK reads a Deploy file and builds a production-like Docker infrastructure for Spryker accordingly.

The tool is used for:

  1. Building production-like Docker images.
  2. Serving as a part of development environment based on Docker.
  3. Simplifying the process of setting up a local demo of Spryker project.

Installing Spryker Docker SDK

Note: Run all the commands below from the root directory of your Spryker project.

To install the Docker SDK:

  1. Fetch Docker SDK tools:
git clone https://github.com/spryker/docker-sdk.git ./docker

Verification: Make sure docker 18.09.1+ and docker-compose 1.23+ have been installed.

  1. Initialize Docker setup:
docker/sdk bootstrap
  1. Build and run Spryker applications:
docker/sdk up

Troubleshooting installation

For installation troubleshooting, see Troubleshooting installation

Documentation

To start working with Spryker in Docker, see Quick start guide.

Contributing to Spryker Docker SDK

For contribution guidelines, see Code contribution guide

Supported services

Service Engine Version(s) ARM support Note
database postgres 9.6*
10
11
12
mysql 5.7
mariadb-10.2 https://endoflife.date/mariadb
mariadb-10.3 https://endoflife.date/mariadb
mariadb-10.4
mariadb-10.5
mariadb-10.6
mariadb-10.11
broker rabbitmq 3.7
3.8
3.9
session redis 5.0*
redis 6.2
key_value_store redis 5.0*
redis 6.2
search elastic 5.6* https://www.elastic.co/support/eol
6.8 https://www.elastic.co/support/eol
7.6
7.10
opensearch 1.3
scheduler jenkins 2.176
2.305
2.324
2.401
2.442
webdriver phantomjs latest*
chromedriver latest
mail_catcher mailhog 1.0
swagger swagger-ui v3.24
kibana kibana 5.6* https://www.elastic.co/support/eol
6.8 https://www.elastic.co/support/eol
7.6
7.10
blackfire blackfire latest

docker-sdk's People

Contributors

alexanderm91 avatar andriitserkovnyi avatar asaulenko avatar asonunique avatar bate avatar bezpiatovs avatar demkos avatar dependabot[bot] avatar dereuromark avatar dimitriytsemma avatar eduard-melnytskyi avatar eugene-chernyi avatar feversocial avatar hacfi avatar incognito avatar kalaputsik avatar marek-obuchowicz avatar michbeck avatar namikk avatar nodiskindrivea avatar olhalivitchuk avatar peresypkin avatar sprymiker avatar sylvain-spryker avatar tvaleriy avatar vladonemo avatar winstonn avatar yaroslav-spryker avatar zeetabit avatar zyuzka avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

docker-sdk's Issues

Set SPRYKER_DEBUG_PROPEL_ENABLED depending if docker debug is set

What is the problem you are trying to solve by the feature?

  • In order to make use of Propel::getConnection()->getLastExecutedQuery() the Propel debug flag need to be set first.
  • It would be great if this can be set similar to SPRYKER_DEBUG_ENABLED which depends on project['docker']['debug']['enabled'].

What is the solution do you propose?

What alternatives have you considered?

Wrong NodeJS version with debian plattform image (image.node.version is ignored)

Which release, branch or hash of Docker SDK are you using?

1.49.7

Which operating system (platform/version/architecture) are you using?

ubuntu-18.04 on GitHub Actions

What is the issue that you're experiencing?

Depending on the Plattform image I get a different issue with NodeJS.
Since the following SDK Update e9ebb66 it is possible to define the required Node and NPM version.

Unfortunately this version will not be used!
Instead, the Node version of the CLI image, which will be installed via "yarn" installation is used, which Node version is installed is depending on the plattform image. See

https://github.com/spryker/docker-sdk/blob/master/images/common/cli/Dockerfile#L35
https://github.com/spryker/docker-sdk/blob/master/images/common/cli/Dockerfile#L46

I have forked the Spryker Demo shop. See below.

What are the steps to reproduce the issue?

I forked the Spryker Demo shop.
I updated deploy.ci.acceptance.mariadb.yml with the following

image:
    node:
        version: 16
        distro: alpine
        npm: 8      

Next I updated the whole github workflow file, see https://github.com/elmerdigital/b2b-demo-shop/blob/master/.github/workflows/ci.yml

To keep it simple, I removed all test excpet the MariaDB acceptance test.
In each test case I just changed the SPRYKER_PLATFORM_IMAGE

To see which NodeJS version is installed I forked the Docker/SDK and added an node --version to images/baked/assets/Dockerfile line 20 elmerdigital@cabe55f

The result is here:
https://github.com/elmerdigital/b2b-demo-shop/actions/runs/3533792118/jobs/5929878947

Depending on the platform image I get instead of the defined and expected Node version 16

Alpine (correct versions)

Debian

What is the expected result of these steps in the absence of the issue?

I would expect the Node version that I defined in my deploy.ci.*.yaml file

What possible solutions and/or workarounds for the issue do you see?

I am not sure if Yarn and the implicit installed nodejs is still required in the CLI image
https://github.com/spryker/docker-sdk/blob/master/images/common/cli/Dockerfile#L35
https://github.com/spryker/docker-sdk/blob/master/images/common/cli/Dockerfile#L46

As far as I know its required in the asset images, and for that there is already the new installation
e9ebb66

So, maybe the solution is to remove the Yarn installation in the CLI image.

Cannot install Spryker using Docker SDK

Which release, branch or hash of Docker SDK are you using?

  • master

Which operating system (platform/version/architecture) are you using?

  • mac os 12.5, intel

What is the issue that you're experiencing?

I am trying to setup Spryker using this instruction - https://docs.spryker.com/docs/scos/dev/setup/installing-spryker-with-docker/installation-guides/installing-in-development-mode-on-macos-and-linux.html#clone-a-demo-shop-and-the-docker-sdk
When I run docker/sdk bootstrap deploy.dev.yml - in ~30 mins I get the following error:

#12 1602.5     Failed to download twig/twig from dist: curl error 28 while downloading https://api.github.com/repos/twigphp/Twig/zipball/ab402673db8746cb3a4c46f3869d6253699f614a: Connection timed out after 75688 milliseconds
#12 1602.5     Now trying to download from source
#12 1602.5   - Syncing twig/twig (v2.15.3) into cache
#12 1677.9 
#12 1677.9  21/21 [============================] 100%
#12 1678.0 In Git.php line 453:
#12 1678.0                                                                                
#12 1678.0   Failed to clone https://github.com/php-fig/container.git via https, ssh pro  
#12 1678.0   tocols, aborting.                                                            
#12 1678.0                                                                                
#12 1678.0   - https://github.com/php-fig/container.git                                   
#12 1678.0     Cloning into bare repository '/home/spryker/.composer/cache/vcs/https---g  
#12 1678.0   ithub.com-php-fig-container.git'...                                          
#12 1678.0     fatal: unable to access 'https://github.com/php-fig/container.git/': Fail  
#12 1678.0   ed to connect to 95.179.149.104 port 1234: Connection refused                
#12 1678.0                                                                                
#12 1678.0   - [email protected]:php-fig/container.git                                       
#12 1678.0     Cloning into bare repository '/home/spryker/.composer/cache/vcs/https---g  
#12 1678.0   ithub.com-php-fig-container.git'...                                          
#12 1678.0     Host key verification failed.                                              
#12 1678.0     fatal: Could not read from remote repository.                              
#12 1678.0                                                                                
#12 1678.0     Please make sure you have the correct access rights                        
#12 1678.0     and the repository exists.                                                 
#12 1678.0                                                                                
#12 1678.0 
#12 1678.0 install [--prefer-source] [--prefer-dist] [--prefer-install PREFER-INSTALL] [--dry-run] [--dev] [--no-suggest] [--no-dev] [--no-autoloader] [--no-progress] [--no-install] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--apcu-autoloader-prefix APCU-AUTOLOADER-PREFIX] [--ignore-platform-req IGNORE-PLATFORM-REQ] [--ignore-platform-reqs] [--] [<packages>...]
#12 1678.0 
------
executor failed running [/bin/sh -c composer install --no-interaction --optimize-autoloader --no-dev]: exit code: 1

What is the expected result of these steps in the absence of the issue?

  • project should be installed

What is the actual result?

  • project is not installed

Is there any other information that might be helpful?

Docker version 20.10.20, build 9fdeb9c

testing.env file only generated for projects with Yves Frontend

Which release, branch or hash of Docker SDK are you using?

3608ed5

Which operating system (platform/version/architecture) are you using?

macOS Big Sur 11.4

What is the issue that you're experiencing?

The testing.env file required for testing is only built when an Yves-Application is configured for a project. This hinders the use of Spryker in projects relying purely on Glue as an interface to custom frontend implementations.

What are the steps to reproduce the issue?

  1. Clone the B2B Demoshop (https://github.com/spryker-shop/b2b-demo-shop.git)
  2. Remove the Yves Application Definitions from deploy.dev.yml file (keys groups/*/applications/yves_*)
  3. Remove the Yves-Related Pyz-Modules (src/Pyz/Yves directory) and Module Tests (tests/PyzTest/Yves directory)
  4. Clone the Docker-SDK (https://github.com/spryker/docker-sdk.git)
  5. Run docker/sdk bootstrap deploy.dev.yml
  6. Run docker/sdk up -t
  7. Run docker/sdk testing

What is the expected result of these steps in the absence of the issue?

The file docker/deployment/default/env/testing.env is generated and docker/sdk testing succesfully opens a testing console.

What is the actual result?

An error is shown that /home/spryker/cli/testing.env does not exist, due to docker/deployment/default/env/testing.env not being generated:

/home/spryker/bin/cli.sh: line 15: /home/spryker/env/testing.env: No such file or directory

What possible solutions and/or workarounds for the issue do you see?

  • For each iteration of the group-loop (
    foreach ($projectData['groups'] ?? [] as $groupName => $groupData) {
    ), create a variable to hold all testing-related parameters
  • Gather testing-related parameters in inner application-loop (
    foreach ($groupData['applications'] ?? [] as $applicationName => $applicationData) {
    )
  • Move testing.env-generation (
    file_put_contents(
    ) to after completion of the per-group application-loop such that it does not depend on a specific application being present
  • Make use of Twig-conditionals in generator/src/templates/env/cli/testing.env.twig to add specific application related environment variables only when related testing parameters have been gathered due to that application (e.g. Yves) being specified in the current group

Is there any other information that might be helpful?

Running tests with --coverage not possible

Which release, branch or hash of Docker SDK are you using?

Latest release

Which operating system (platform/version/architecture) are you using?

Windows 10 + WSL2 (Ubuntu)
Azure Pipelines agent based on Ubuntu Bionic Beaver

What is the issue that you're experiencing?

not possible to run tests with --coverage option

What are the steps to reproduce the issue?

just run tests, e.g.
./docker/sdk testing -xvt codecept run -c codeception.functional.yml --xml --coverage-xml

What is the expected result of these steps in the absence of the issue?

The test cases are executed OK and the coverage.xml is generated

What is the actual result?

The test run fails on errror:
Code coverage needs to be enabled in php.ini by setting 'xdebug.mode' to 'coverage'

What possible solutions and/or workarounds for the issue do you see?

Changing
xdebug.mode=debug
to
xdebug.mode=debug,coverage
in 69-xdebug.ini file

Is there any other information that might be helpful?

Adjust requirements for latest mutagen beta.

What is the problem you are trying to solve by the feature?

Stuck session on newest Docker Desktop:
mutagen-io/mutagen#223

What is the solution do you propose?

Check if mutagen 0.12.0-beta2 is installed.

What changes in deploy.yml format do you propose?

What changes in command line interface do you propose?

What alternatives have you considered?

Missing SPRYKER_FE_HOST & SPRYKER_FE_PORT in glue-storefront

Which release, branch or hash of Docker SDK are you using?

Tag 1.49.6

Which operating system (platform/version/architecture) are you using?

MacOS M1 Arm

What is the issue that you're experiencing?

Missing SPRYKER_FE_HOST and SPRYKER_FE_PORT in glue-storefront application

What are the steps to reproduce the issue?

Call a glue-storefront-api and check the yves host/port value

What is the expected result of these steps in the absence of the issue?

We need in some api resource the Yves Host:Port to generate a deeplink to yves in json response

What is the actual result?

not-configured-host is just used as fallback value in config

What possible solutions and/or workarounds for the issue do you see?

Add this code to this file generator/src/templates/nginx/http/glue-storefront.server.conf.twig

{% if project['_endpointMap'][endpointData['store']]['yves'] is not empty %}
    fastcgi_param SPRYKER_FE_HOST "{{ (project['_endpointMap'][endpointData['store']]['yves'] | split(':'))[0] | default('') }}";
    fastcgi_param SPRYKER_FE_PORT "{{ (project['_endpointMap'][endpointData['store']]['yves'] | split(':'))[1] | default(project['_defaultPort']) }}";
{% endif %}

Is there any other information that might be helpful?

No.

Kubernetes Support?

What is the problem you are trying to solve by the feature?

Would like to have Kubernetes Support for easier and faster development. Example automatically created ReviewApps over Kubernetes + Gitlab CI/CD instead of vms which has Docker installed.

Docker external cache sources

I am not sure, if this is just a missing feature or if there is a reason that the docker/sdk does not support external cache sources.

https://docs.docker.com/engine/reference/commandline/build/#specifying-external-cache-sources

As background information, the docker/sdk for local usage is awesome, but we also run it in our CI for tests and building images.
In CI we dont have a shared docker cache, if we use a custom remote docker cache (which could be possible) we get problems with mounting files. So, the best improvement would be to use external cache sources. (--build-arg BUILDKIT_INLINE_CACHE=1 --cache-from IMAGE:latest)

So my first question is, is this just a missing feature until now or is there a reason that the docker/sdk does not support that?

Support for Mac M1

Which release, branch or hash of Docker SDK are you using?

1.30.0

Which operating system (platform/version/architecture) are you using?

Mac Os Big Sur, Mac Book Pro M1

What is the issue that you're experiencing?

On docker/sdk bootstrap deploy.dev.yml the warning WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested appears.
And if i try to start the containers with docker/sdk up this Error appears:

[+] Building 6.7s (21/21) FINISHED                                                                                                                                               
 => [internal] load build definition from Dockerfile                                                                                                                        0.3s
 => => transferring dockerfile: 37B                                                                                                                                         0.0s
 => [internal] load .dockerignore                                                                                                                                           0.5s
 => => transferring context: 2B                                                                                                                                             0.0s
 => resolve image config for docker.io/docker/dockerfile:experimental                                                                                                       2.3s
 => CACHED docker-image://docker.io/docker/dockerfile:experimental@sha256:600e5c62eedff338b3f7a0850beb7c05866e0ef27b2d2e8c02aa468e78496ff5                                  0.0s
 => [internal] load metadata for docker.io/spryker/php:7.3-alpine3.12                                                                                                       0.9s
 => [internal] load build context                                                                                                                                           0.2s
 => => transferring context: 376B                                                                                                                                           0.0s
 => [ 1/14] FROM docker.io/spryker/php:7.3-alpine3.12@sha256:84ccd6d38962b649b3ff349831ca3b31b090154399ec06ae1f9f35c4ca2fe30f                                               0.0s
 => CACHED [ 2/14] WORKDIR /data                                                                                                                                            0.0s
 => CACHED [ 3/14] RUN mkdir -p /var/log/spryker && chown spryker:spryker /var/log/spryker                                                                                  0.0s
 => CACHED [ 4/14] RUN mkdir -p /home/spryker/.ssh && chmod 0700 /home/spryker/.ssh                                                                                         0.0s
 => CACHED [ 5/14] RUN bash -c '[ ! -z "${KNOWN_HOSTS}" ] && ssh-keyscan -t rsa ${KNOWN_HOSTS} >> /home/spryker/.ssh/known_hosts || true'                                   0.0s
 => CACHED [ 6/14] RUN chown spryker:spryker -R /home/spryker/.ssh                                                                                                          0.0s
 => CACHED [ 7/14] COPY php/php-fpm.d/worker.conf /usr/local/etc/php-fpm.d/worker.conf                                                                                      0.0s
 => CACHED [ 8/14] COPY php/php.ini /usr/local/etc/php/                                                                                                                     0.0s
 => CACHED [ 9/14] COPY php/conf.d/90-opcache.ini /usr/local/etc/php/conf.d                                                                                                 0.0s
 => CACHED [10/14] RUN rm -f /usr/local/etc/php/conf.d/opcache.ini                                                                                                          0.0s
 => CACHED [11/14] RUN mv /usr/local/etc/php/disabled/blackfire.ini /usr/local/etc/php/conf.d/90-blackfire.ini                                                              0.0s
 => CACHED [12/14] COPY php/conf.d/99-from-deploy-yaml-php.ini /usr/local/etc/php/conf.d/                                                                                   0.0s
 => CACHED [13/14] COPY --chown=spryker:spryker jenkins/jenkins.docker.xml.twig /home/spryker/jenkins.docker.xml.twig                                                       0.0s
 => CACHED [14/14] COPY --chown=spryker:spryker php/build.php /home/spryker/build.php                                                                                       0.0s
 => exporting to image                                                                                                                                                      1.6s
 => => exporting layers                                                                                                                                                     0.0s
 => => writing image sha256:ac0090d6674e0bbcc7bec2cc67a4448ba1dbb6fed9a684a3c494009925289d48                                                                                0.0s
 => => naming to docker.io/library/spryker_b2c_dev_base_app:dev                                                                                                             0.0s
[+] Building 3.5s (5/5) FINISHED                                                                                                                                                 
 => [internal] load build definition from Dockerfile                                                                                                                        0.3s
 => => transferring dockerfile: 37B                                                                                                                                         0.0s
 => [internal] load .dockerignore                                                                                                                                           0.5s
 => => transferring context: 35B                                                                                                                                            0.0s
 => resolve image config for docker.io/docker/dockerfile:experimental                                                                                                       0.7s
 => CACHED docker-image://docker.io/docker/dockerfile:experimental@sha256:600e5c62eedff338b3f7a0850beb7c05866e0ef27b2d2e8c02aa468e78496ff5                                  0.0s
 => ERROR [internal] load metadata for docker.io/library/spryker_b2c_dev_base_app:dev                                                                                       1.3s
------
 > [internal] load metadata for docker.io/library/spryker_b2c_dev_base_app:dev:
------
failed to solve with frontend dockerfile.v0: failed to solve with frontend gateway.v0: rpc error: code = Unknown desc = pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed

What are the steps to reproduce the issue?

Simply try to install Spryker on an Mac M1 machine.

What is the expected result of these steps in the absence of the issue?

The Containers would be getting build und started.

What is the actual result?

The error appears and stops the Process

What possible solutions and/or workarounds for the issue do you see?

Make the Image ARM compatible. Or let it run through Rosetta 2.

Is there any other information that might be helpful?

[windows] error when running docker/sdk up: invalid characters for a local volume name

Which release, branch or hash of Docker SDK are you using?

master (1.47.1)
2b08ee6

Which operating system (platform/version/architecture) are you using?

Windows 10
Version 21H1 (Build 19043.1645)
x64

What is the issue that you're experiencing?

When running docker/sdk up, an error occurs:
Error response from daemon: create ./docker/deployment/default/context/ssh/ssh-agent.mock: "./docker/deployment/default/context/ssh/ssh-agent.mock" includes invalid characters for a local volume name, only "[a-zA-Z0-9][a-zA-Z0-9_.-] " are allowed. If you intended to pass a host directory, use absolute path

What are the steps to reproduce the issue?

docker/sdk boot deploy.dev.yml && docker/sdk up

What is the expected result of these steps in the absence of the issue?

Local environment starts

What is the actual result?

Error occurs and the environment does not start

What possible solutions and/or workarounds for the issue do you see?

Downgrading to an older docker/sdk version works: 1.45.4

Is there any other information that might be helpful?

docker/sdk reset command fails to run transfer:generate

Which release, branch or hash of Docker SDK are you using?

Unfortunately I don't know.

Which operating system (platform/version/architecture) are you using?

macOS Monterey 12.6

What is the issue that you're experiencing?

Running docker/sdk reset fails to generate transfer files.

What are the steps to reproduce the issue?

What is the expected result of these steps in the absence of the issue?

The src/Generated files should be removed with the docker/sdk reset command, because old generated files can cause issues.

What is the actual result?

It fails when running vendor/bin/console transfer:generate

What possible solutions and/or workarounds for the issue do you see?

Include rm -rf vendor src/Generated command for the transfer:generate or docker/sdk reset before running vendor/bin/console transfer:generate

Is there any other information that might be helpful?

feat: allow build/export of images explicitly

What is the problem you are trying to solve by the feature?

Currently, it is only possible to build all docker images sequentially via docker/sdk export images.
The build takes ~10min with empty layer caches and a base/empty version of a store.

What solution do you propose?

I'd like to build each image individually with the possibility of --no-force to let docker decide via the layer SHA if it needs to rebuild

  • and tag
  • and push it optionally
docker/sdk export image application --no-force --tag --push
docker/sdk export image cli --no-force --tag --push
docker/sdk export image frontend --no-force --tag --push
docker/sdk export image assets --no-force --tag --push

Proposal
split the following functions

  • Command::export(): here
  • Images::_buildApp(): see here

What changes in deploy.yml format do you propose?

none

What changes in command line interface do you propose?

as proposed above

What alternatives have you considered?

only docker/sdk export asset, however it does not speed up, as docker/sdk export images always rebuilds due to the --force flag

Sporadical WebDriver timeout in acceptance tests

Which release, branch or hash of Docker SDK are you using?

master

Which operating system (platform/version/architecture) are you using?

ubuntu-18.04 on GitHub Actions

What is the issue that you're experiencing?

The following error happens only sporadically, after a restart of the failed job it works without any issues.
In this case it was happen on Alpine, but it could also happen on Debian. Its totally sporadical.
Also the test case, in this example it is CmsGuiCreatePageCest but it could also be another test case.

https://github.com/elmerdigital/b2b-demo-shop/actions/runs/3540552778/jobs/5943741993

SCR-20221124-jtb

What are the steps to reproduce the issue?

I forked the current Spryker Demo Shop (https://github.com/elmerdigital/b2b-demo-shop).
The github CI which I use is the following (https://github.com/elmerdigital/b2b-demo-shop/blob/master/.github/workflows/ci.yml)

git clone https://github.com/spryker/docker-sdk.git ./docker
docker/sdk boot -v deploy.ci.acceptance.mariadb.yml
docker/sdk up -t
docker/sdk testing console queue:worker:start --stop-when-empty
docker/sdk testing codecept run -c codeception.acceptance.yml

What is the expected result of these steps in the absence of the issue?

A successful Github job

new security requirements for TLS server certificates in iOS 13 and macOS 10.15.

Apple has new security requirements for TLS server certificates in iOS 13 and macOS 10.15[1].
the result is following error (see screenshot below):

NET::ERR_CERT_INVALID

an inconvenient bypass this error (in Chrome) is to type thisisunsafe.

a more convenient solution would be to provide a valid server cert with invalid cert authority, which provides a link to access the page (see screenshot below)

[1] https://support.apple.com/en-us/HT210176

NET ERR_CERT_AUTHORITY_INVALID

NET ERR_CERT_INVALID

RUN /usr/bin/install -d -m 777 /var/run/opcache/debug - Permission denied

Which release, branch or hash of Docker SDK are you using?

d72ae2f (HEAD -> origin/master, tag: 1.42.1)

Which operating system (platform/version/architecture) are you using?

macOs Monterey

What is the issue that you're experiencing?

Running docker/sdk up:

RUN /usr/bin/install -d -m 777 /var/run/opcache/debug:
#6 0.187 /usr/bin/install: cannot create directory '/var/run/opcache': Permission denied

What are the steps to reproduce the issue?

Running docker/sdk up

What is the expected result of these steps in the absence of the issue?

local environment should run

What is the actual result?

What possible solutions and/or workarounds for the issue do you see?

Is there any other information that might be helpful?

ERROR resolve image config for docker.io/docker/dockerfile:experimental on widnows

On Linux system everything is working fine, but on windows and WSL i got error during docker/sdk boot:

dawid@DESKTOP-IK089RK:/c/Users/schmi/dev/spryker$ docker/sdk boot

[+] Building 0.2s (3/3) FINISHED
 => [internal] load build definition from Dockerfile                                                                                         0.0s  => => transferring dockerfile: 38B                                                                                                          0.0s  => [internal] load .dockerignore                                                                                                            0.0s  => => transferring context: 34B                                                                                                             0.0s  => ERROR resolve image config for docker.io/docker/dockerfile:experimental                                                                  0.2s ------
 > resolve image config for docker.io/docker/dockerfile:experimental:
------
failed to solve with frontend dockerfile.v0: failed to solve with frontend gateway.v0: rpc error: code = Unknown desc = error getting credentials - err: exit status 1, out: `Error spawning command line “dbus-launch --autolaunch= --binary-syntax --close-stderr”: Child process exited with code 1`
dawid@DESKTOP-IK089RK:/c/Users/schmi/dev/spryker$
dawid@DESKTOP-IK089RK:/c/Users/schmi/dev/spryker$ docker/sdk boot
[+] Building 0.2s (3/3) FINISHED
 => [internal] load build definition from Dockerfile                                                                                         0.0s  => => transferring dockerfile: 38B                                                                                                          0.0s  => [internal] load .dockerignore                                                                                                            0.0s  => => transferring context: 34B                                                                                                             0.0s  => ERROR resolve image config for docker.io/docker/dockerfile:experimental                                                                  0.2s ------
 > resolve image config for docker.io/docker/dockerfile:experimental:
------
failed to solve with frontend dockerfile.v0: failed to solve with frontend gateway.v0: rpc error: code = Unknown desc = error getting credentials - err: exit status 1, out: `Error spawning command line “dbus-launch --autolaunch= --binary-syntax --close-stderr”: Child process exited with code 1`

I made everything like in this documentation: https://documentation.spryker.com/docs/docker-installation-prerequisites-windows

My deamon.json look like that:

{
  "registry-mirrors": [],
  "insecure-registries": [],
  "debug": true,
  "experimental": true,
  "features": {
    "buildkit": true
  }
}

On Linux systems 'docker-compose' is not found when 'docker compose' is installed

Which release, branch or hash of Docker SDK are you using?

master

Which operating system (platform/version/architecture) are you using?

Linux (Ubuntu 22.10, Debian 11)

Docker:

vagrant@99-bullseye:~/git/suite/docker$ docker version
Client: Docker Engine - Community
 Version:           20.10.21
 API version:       1.41
 Go version:        go1.18.7
 Git commit:        baeda1f
 Built:             Tue Oct 25 18:02:28 2022
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.21
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.18.7
  Git commit:       3056208
  Built:            Tue Oct 25 18:00:19 2022
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.9
  GitCommit:        1c90a442489720eec95342e1789ee8a5e1b9536f
 runc:
  Version:          1.1.4
  GitCommit:        v1.1.4-0-g5fd4c4d
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Docker Compose:

vagrant@99-bullseye:~/git/suite/docker$ docker compose version
Docker Compose version v2.12.2

What is the issue that you're experiencing?

I get

vagrant@99-bullseye:~/git/suite$ docker/sdk boot deploy.yml 
'docker-compose' is not found. Please, make sure this application is installed and added to PATH. 

although docker compose v2 is installed

What are the steps to reproduce the issue?

  1. Move to a real linux cli, e.g. via
    1. Start a real linux node
    2. Install docker (e.g. "apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin")
  2. Clone docker-sdk
  3. run 'docker/sdk boot deploy.yml '

What is the expected result of these steps in the absence of the issue?

Docker sdk would run the commands 'boot' and 'run' without exiting because of missing 'docker-compose' binary.

What is the actual result?

vagrant@99-bullseye:~/git/suite$ docker/sdk boot deploy.yml 
'docker-compose' is not found. Please, make sure this application is installed and added to PATH. 

What possible solutions and/or workarounds for the issue do you see?

A workaround is to symlink in the OS: ln -s /usr/libexec/docker/cli-plugins/docker-compose /usr/local/bin/docker-compose

Better would be to remove the required dependency to the binary 'docker-compose' within the SDK

Is there any other information that might be helpful?

Slow builds

Which release, branch or hash of Docker SDK are you using?

2958d59

Which operating system (platform/version/architecture) are you using?

ubuntu-18.04 on GitHub Actions

What is the issue that you're experiencing?

We are experiencing very slow builds on GitHub Actions.

When running acceptance and functional tests, the jobs run ~11 and ~7 minutes respectively. Most of the time they are busy building Docker images.

We would like to speed up the builds by caching Docker layers. Unfortunately, it is unclear how to do that.

Long build times

  • eat up build minutes
  • force developers to push rarely
  • force developers to push larger commits

What are the steps to reproduce the issue?

See https://github.com/spryker-shop/b2b-demo-shop/blob/bcc57623dcf9c483bf5fb4444745ce13efac6fa6/.github/workflows/ci.yml.

See https://github.com/spryker-shop/b2b-demo-shop/actions/runs/2538229226:

CleanShot 2022-06-30 at 09 59 25@2x

What is the expected result of these steps in the absence of the issue?

Fast builds!

What is the actual result?

Slow builds. 🐌

What possible solutions and/or workarounds for the issue do you see?

Using Docker layer caching.

Is there any other information that might be helpful?

No device /dev/stderr exists

Which release, branch or hash of Docker SDK are you using?

master branch

Which operating system (platform/version/architecture) are you using?

Azure Pipelines ubuntu-18.04 VMImage

What is the issue that you're experiencing?

docker/sdk can't be executed. Failing with:
./docker/sdk: line 60: /dev/stderr: No such device or address

What are the steps to reproduce the issue?

Just run for instance docker/sdk boot deploy.yml as an Azure Pipeline task

What is the expected result of these steps in the absence of the issue?

The docker/sdk runs with no error

What is the actual result?

Build fails

What possible solutions and/or workarounds for the issue do you see?

Replace >/dev/stderr with >&2 in all bash scripts

Is there any other information that might be helpful?

Add `Makefile` support

What is the problem you are trying to solve by the feature?

I would like to be able to use Makefiles after entering the terminal running

docker/sdk cli

What is the solution do you propose?

Provide Makefile support.

What changes in deploy.yml format do you propose?

n/a

What changes in command line interface do you propose?

n/a

What alternatives have you considered?

I have been using composer scripts, but they do not work as well as Makefiles.

docker/sdk up fails when tideways service is enabled

Which release, branch or hash of Docker SDK are you using?

Latest master ee7e4aa

Which operating system (platform/version/architecture) are you using?

Linux

What is the issue that you're experiencing?

docker/sdk up fails with "Aborted install..." when having the tideways service enabled

What are the steps to reproduce the issue?

git clone https://github.com/spryker-shop/b2c-demo-shop.git

cd b2c-demo-shop

git clone https://github.com/spryker/docker-sdk.git docker

cat <<EOF | git apply
> diff --git a/deploy.dev.yml b/deploy.dev.yml
index e6263864d..d7323a8d6 100644
--- a/deploy.dev.yml
+++ b/deploy.dev.yml
@@ -7,8 +7,11 @@ environment: docker.dev
 image:
     tag: spryker/php:7.4-alpine3.12
     php:
+        ini:
+            "tideways.connection": "tcp://tideways:9135"
         enabled-extensions:
             - blackfire
+            - tideways
     environment:
         STORE_NAME_REFERENCE_MAP: '{"DE":"dev-DE","AT":"dev-AT","US":"dev-US"}'

@@ -199,6 +202,11 @@ services:
         engine: dashboard
         endpoints:
             spryker.local:
+    tideways:
+        engine: tideways
+        apikey: abcdefg
+        environment: development
+        cli-enabled: false

 docker:

EOF

docker/sdk bootstrap deploy.dev.yml ; docker/sdk up

What is the expected result of these steps in the absence of the issue?

Environment gets built completely and started.

What is the actual result?

Install docker environment
========================================================================================================================


 Section build


Command generate-transfers [vendor/bin/console transfer:generate] (In progress...)
Store: DE | Environment: docker.dev

In CommandLineExecutable.php line 107:

  Aborted install...


install [-r|--recipe RECIPE] [-d|--dry-run] [-s|--sections SECTIONS] [-g|--groups GROUPS] [-x|--exclude EXCLUDE] [-e|--include-excluded INCLUDE-EXCLUDED] [-i|--interactive] [-b|--breakpoint] [-a|--ask-before-continue] [-l|--log] [--] [<store>]

What possible solutions and/or workarounds for the issue do you see?

A workaround to solve the issue is to apply this patch into the docker-sdk repo:

cat <<'EOF' | git apply
diff --git a/bin/sdk/compose.sh b/bin/sdk/compose.sh
index fb9e4cc..067ac99 100644
--- a/bin/sdk/compose.sh
+++ b/bin/sdk/compose.sh
@@ -35,7 +35,7 @@ function Compose::ensureRunning() {
 function Compose::ensureCliRunning() {
     local isCliRunning=$(docker ps --filter 'status=running' --filter "ancestor=${SPRYKER_DOCKER_PREFIX}_run_cli:${SPRYKER_DOCKER_TAG}" --filter "name=${SPRYKER_DOCKER_PREFIX}_cli_*" --format "{{.Names}}")
     if [ -z "${isCliRunning}" ]; then
-        Compose::run --no-deps cli cli_ssh_relay
+        Compose::run --no-deps cli cli_ssh_relay tideways
         Registry::Flow::runAfterCliReady
     fi
 }
EOF

Is there any other information that might be helpful?

Why does the above workaround fix the issue; what is the original problem? The problem is that if we enable the tideways integration and set tideways.connection to "tcp://tideways:9135" in the php cli container, then all php processes that gets started on the container will try to reach the tideways container on port 9135.

This can be proven by executing above "steps to reproduce", and afterwards (after the error occured) jumping into the cli container and running a simple script:

docker/sdk cli

cat <<'EOF' > foobar.php
<?php
set_error_handler(function($errno, $errstr, $errfile, $errline, $errcontext) {
    var_dump($errno);
    var_dump($errstr);
    var_dump($errfile);
    var_dump($errline);
    var_dump($errcontext);
    throw new Exception();
});
EOF

time php foobar.php
echo $?

Output:

int(2)
string(76) "Unknown: php_network_getaddresses: getaddrinfo failed: Name does not resolve"
string(7) "Unknown"
int(0)
NULL

real    0m5.044s
user    0m0.016s
sys     0m0.023s
255

What happens here? Apparently an error gets thrown with "Unkown" origin. To understand the issue better, try to run a very simple php script:

cat <<'EOF' > foobar.php
<?php
var_dump('Hello world');
EOF

time php foobar.php
echo $?

Output:

string(11) "Hello world"

real    0m10.042s
user    0m0.010s
sys     0m0.023s
0

Why didn't we see an error here? Because we have not configured error handling, and the error that is being thrown is coming from the tideways php extension, which will throw the error after the script already has run. Also note the very long script running time of 5-10 seconds.

So, what is the problem? The problem is that we configure the php cli container to talk to a tideways container via "tcp://tideways:9135", but this container is not yet started at this point of the build process. A workaround would be to start the tideways container together with the cli container, see above workaround. But I hope the maintainers of this project will find a better solution.

Why this is an issue for Spryker projects

Spryker overrides the default error handler in all console commands via the \Spryker\Zed\Console\Communication\Bootstrap\ConsoleBootstrap::__construct call to Environment::initialize, which will forward to ErrorHandlerEnvironment::initialize, which in ::setErrorHandler will set a custom error handler, that exactly will do what the above proof showed: It will throw an exception when it receives an error. That is also why the steps to reproduce produce the "Aborted install..." error: In the process of docker/sdk up, vendor/bin/console will be called for the first time, and this is a php script. This script does it's job (in this generating the transfers correctly), and afterwards the tideways extension tries to reach the tideways container, but doesn't find the dns record because the container is not started, hence a php error is thrown, which will be caught by the Spryker error handler, converted into an exception, and the console command will then return a non-zero exitcode (because of an uncaught exception). As this all happens within the shutdown procedure of the php script already, we don't see any real "Uncaught exception" message anymore.

Another example to prove the problem is to run the console command manually again, after the above steps to reproduce lead to the problem:

time docker/sdk console transfer:generate
echo $?

Output:

-->  DEVELOPMENT MODE
Store: DE | Environment: docker.dev

real    0m9.216s
user    0m1.862s
sys     0m0.247s
255

^ Note: No error visible (exception gets swallowed), but exit-code 255.

Don't use "docker" as recommended folder name

I have a "Projects" folder with a lot of projects inside. And I clone your project into it. It's not that useful to have a folder called "docker" if I am looking for the "spryker-docker-sdk" or something like that :)

Section demodata is hard-coded, impossible to use meaningful name instead

Which release, branch or hash of Docker SDK are you using?

364e266

Which operating system (platform/version/architecture) are you using?

MacOS

What is the issue that you're experiencing?

The concept of "demo data" is hard-coded into scripts, making it impossible to rename the corresponding demodata sections in installation recipes to something that makes more sense, for example, data.

What are the steps to reproduce the issue?

Here are examples from installation recipes for production environments for the https://github.com/spryker-shop/b2b-demo-shop:

❗ If you rename the sections demodata, because in a production environment I clearly do not want to import demo data, but actual data, data is not imported anymore, because the sections are hard-coded into scripts:

generator/src/templates/deploy.bash.twig

The template contains two references to scripts that are included.

import command/runtime/demo.sh

bin/command/runtime/demo.sh

https://github.com/spryker/docker-sdk/blob/364e266cbf90f53a2008cfa9cd7183cd63139a33/bin/command/runtime/demo.sh

data/demo.sh

The name of the script itself indicates that it is used for demo data only, but why would anyone want to import demo data in a production system? We want to import production data - or just data. Let me decide what kind of data I import, rather than pushing the concept of demo data on me.

https://github.com/spryker/docker-sdk/blob/364e266cbf90f53a2008cfa9cd7183cd63139a33/bin/sdk/data/demo.sh

local demoDataSection=${1:-demodata}
Compose::exec "vendor/bin/install${verboseOption} -r ${SPRYKER_PIPELINE} -s init-storages-per-region -s ${demoDataSection}"

initial clone does not seem to work

cp: deploy.yml: No such file or directory

cloned the sdk and then manual the sdk tools

but looks like the path to deploy.yml is not valid.

 bash docker/sdk bootstrap
bash: docker/sdk: No such file or directory
[10:01:18] ross:docker-sdk git:(master) $ git clone https://github.com/spryker/docker-sdk.git ./docker --depth 1
Cloning into './docker'...
remote: Enumerating objects: 158, done.
remote: Counting objects: 100% (158/158), done.
remote: Compressing objects: 100% (121/121), done.
remote: Total 158 (delta 25), reused 95 (delta 14), pack-reused 0
Receiving objects: 100% (158/158), 73.96 KiB | 312.00 KiB/s, done.
Resolving deltas: 100% (25/25), done.
[10:01:38] ross:docker-sdk git:(master*) $ bash docker/sdk bootstrap
File "deploy.yml" is not accessible.
[+] Building 20.3s (19/19) FINISHED
 => [internal] load build definition from Dockerfile                                                                                                                                                                                                                                                                                                                   0.0s
 => => transferring dockerfile: 1.05kB                                                                                                                                                                                                                                                                                                                                 0.0s
 => [internal] load .dockerignore                                                                                                                                                                                                                                                                                                                                      0.0s
 => => transferring context: 48B                                                                                                                                                                                                                                                                                                                                       0.0s
 => resolve image config for docker.io/docker/dockerfile:experimental                                                                                                                                                                                                                                                                                                  2.5s
 => docker-image://docker.io/docker/dockerfile:experimental@sha256:888f21826273409b5ef5ff9ceb90c64a8f8ec7760da30d1ffbe6c3e2d323a7bd                                                                                                                                                                                                                                    1.5s
 => => resolve docker.io/docker/dockerfile:experimental@sha256:888f21826273409b5ef5ff9ceb90c64a8f8ec7760da30d1ffbe6c3e2d323a7bd                                                                                                                                                                                                                                        0.0s
 => => sha256:ee85655c57140bd20a5ebc3bb802e7410ee9ac47ca92b193ed0ab17485024fe5 527B / 527B                                                                                                                                                                                                                                                                             0.0s
 => => sha256:80b5f664ac0c5f6b89608f7b0afd9548ac5b2d4cd631b7b723d9f2edca8676d9 897B / 897B                                                                                                                                                                                                                                                                             0.0s
 => => sha256:73e11b97eeae87ce062a224a9ff2d7f8a919d3b50e014a3f33a79b0c219a7003 8.82MB / 8.82MB                                                                                                                                                                                                                                                                         1.0s
 => => sha256:888f21826273409b5ef5ff9ceb90c64a8f8ec7760da30d1ffbe6c3e2d323a7bd 2.03kB / 2.03kB                                                                                                                                                                                                                                                                         0.0s
 => => extracting sha256:73e11b97eeae87ce062a224a9ff2d7f8a919d3b50e014a3f33a79b0c219a7003                                                                                                                                                                                                                                                                              0.2s
 => [internal] load metadata for docker.io/spryker/php:7.3                                                                                                                                                                                                                                                                                                             0.9s
 => [internal] load metadata for docker.io/library/alpine:3.9                                                                                                                                                                                                                                                                                                          0.0s
 => [spryker_app_dependencies 1/5] FROM docker.io/spryker/php:7.3@sha256:670e6ca57dbb3131f60e38f1f763e4edc796fb1b602975bd81aec52115b6fa6c                                                                                                                                                                                                                             10.0s
 => => resolve docker.io/spryker/php:7.3@sha256:670e6ca57dbb3131f60e38f1f763e4edc796fb1b602975bd81aec52115b6fa6c                                                                                                                                                                                                                                                       0.0s
 => => sha256:670e6ca57dbb3131f60e38f1f763e4edc796fb1b602975bd81aec52115b6fa6c 4.50kB / 4.50kB                                                                                                                                                                                                                                                                         0.0s
 => => sha256:bec6dfd5a6c7ebe378f1c41d2f47e46610732aaae1064abd05476f8a39ff0aed 19.01kB / 19.01kB                                                                                                                                                                                                                                                                       0.0s
 => => sha256:112aa0ae7f66a948c20b32467b3fe18d4bd46f9f4df2482c698fb32dd6dddfab 227B / 227B                                                                                                                                                                                                                                                                             0.2s
 => => sha256:2ccb07e9b7f72ba51677e0ce7986c590760e1cace17931f76da75685ee5f0eca 1.25kB / 1.25kB                                                                                                                                                                                                                                                                         0.5s
 => => sha256:7270d632124c8dabb3e1a1422cb5be11fd258bc4b112d4117d29780cc65fed4c 1.44MB / 1.44MB                                                                                                                                                                                                                                                                         0.5s
 => => sha256:7416efcad7752ab289b252d731e8a657e6be0b3a8839f2f62978f52797c476e0 12.11MB / 12.11MB                                                                                                                                                                                                                                                                       2.7s
 => => extracting sha256:7270d632124c8dabb3e1a1422cb5be11fd258bc4b112d4117d29780cc65fed4c                                                                                                                                                                                                                                                                              0.1s
 => => sha256:9cefa67d13ae6ca2f5a068be198b0b86df86d71c3bae9eea074bd9bb117dc1ba 497B / 497B                                                                                                                                                                                                                                                                             0.7s
 => => sha256:d008987dd8f9763547905d39bfde02e3c39c97fd0ed069368815bbb8e513ec96 17.31MB / 17.31MB                                                                                                                                                                                                                                                                       4.0s
 => => extracting sha256:2ccb07e9b7f72ba51677e0ce7986c590760e1cace17931f76da75685ee5f0eca                                                                                                                                                                                                                                                                              0.0s
 => => extracting sha256:112aa0ae7f66a948c20b32467b3fe18d4bd46f9f4df2482c698fb32dd6dddfab                                                                                                                                                                                                                                                                              0.0s
 => => sha256:5e7ef029c0960fa49cec045b3fd62c3d442384c1e0c3c508de9219521fa3c978 2.20kB / 2.20kB                                                                                                                                                                                                                                                                         0.9s
 => => sha256:ed1ef40fd69436809f9251f4b9039eaedf805fe4e32bb08c3dcee1f7cb4436cc 72.41kB / 72.41kB                                                                                                                                                                                                                                                                       1.2s
 => => sha256:d6a5c78fefbc1b7b83f3ae3e13360c23256a287f1e3a23a1c4b14fb7cabfca2f 8.41kB / 8.41kB                                                                                                                                                                                                                                                                         1.4s
 => => sha256:b2ffb4d163704bc7ecb82a8f5aa759baeab69150ac3d4e1dce0f9faa779d6600 93B / 93B                                                                                                                                                                                                                                                                               1.6s
 => => sha256:03c6329ad91a282505dfec3a4e9a7e2a01fd93a80828b5cc9745a954b62009d8 48.99MB / 48.99MB                                                                                                                                                                                                                                                                       7.7s
 => => extracting sha256:7416efcad7752ab289b252d731e8a657e6be0b3a8839f2f62978f52797c476e0                                                                                                                                                                                                                                                                              0.2s
 => => sha256:12984c9fff182c0dc4ba5f61a9a0cb0f5afadcbf70292d65c06a680d5604a371 496.93kB / 496.93kB                                                                                                                                                                                                                                                                     3.1s
 => => extracting sha256:9cefa67d13ae6ca2f5a068be198b0b86df86d71c3bae9eea074bd9bb117dc1ba                                                                                                                                                                                                                                                                              0.0s
 => => sha256:593f52084135e2138cb26d2e1237d7034a8c80e50a14d9c1c1b41a296dfba1a7 1.30kB / 1.30kB                                                                                                                                                                                                                                                                         3.3s
 => => sha256:f4d0198516bccfdd94b290cd1df05001170c324500d71e0f5e80b60e5845ddc5 236B / 236B                                                                                                                                                                                                                                                                             3.5s
 => => sha256:35278b47ab256a3be461c75b8d8c2ae83ae6ea04cfb202e28c2195ebb0637427 505B / 505B                                                                                                                                                                                                                                                                             4.2s
 => => extracting sha256:d008987dd8f9763547905d39bfde02e3c39c97fd0ed069368815bbb8e513ec96                                                                                                                                                                                                                                                                              1.1s
 => => sha256:76a55975956e53808ab5cc933ce0212eb91e05162ac8a9c12523f17c78c615d7 265B / 265B                                                                                                                                                                                                                                                                             4.2s
 => => sha256:37eb6a1ed00f803e4608d3fe7cea489f6b8baef1565d39107edc9c023f39f442 22.76kB / 22.76kB                                                                                                                                                                                                                                                                       4.3s
 => => sha256:04263926308c0fd0d1f30d8303615bb1191baeeff9c3e4562434e5b8baa17ca1 432B / 432B                                                                                                                                                                                                                                                                             4.5s
 => => sha256:07a44844b644c629b273dccd3bf998437bd5b701d30024b914d4ee3bd59d86a3 1.49MB / 1.49MB                                                                                                                                                                                                                                                                         5.0s
 => => extracting sha256:5e7ef029c0960fa49cec045b3fd62c3d442384c1e0c3c508de9219521fa3c978                                                                                                                                                                                                                                                                              0.0s
 => => extracting sha256:ed1ef40fd69436809f9251f4b9039eaedf805fe4e32bb08c3dcee1f7cb4436cc                                                                                                                                                                                                                                                                              0.0s
 => => extracting sha256:d6a5c78fefbc1b7b83f3ae3e13360c23256a287f1e3a23a1c4b14fb7cabfca2f                                                                                                                                                                                                                                                                              0.0s
 => => extracting sha256:b2ffb4d163704bc7ecb82a8f5aa759baeab69150ac3d4e1dce0f9faa779d6600                                                                                                                                                                                                                                                                              0.0s
 => => extracting sha256:03c6329ad91a282505dfec3a4e9a7e2a01fd93a80828b5cc9745a954b62009d8                                                                                                                                                                                                                                                                              1.1s
 => => extracting sha256:12984c9fff182c0dc4ba5f61a9a0cb0f5afadcbf70292d65c06a680d5604a371                                                                                                                                                                                                                                                                              0.1s
 => => extracting sha256:593f52084135e2138cb26d2e1237d7034a8c80e50a14d9c1c1b41a296dfba1a7                                                                                                                                                                                                                                                                              0.0s
 => => extracting sha256:f4d0198516bccfdd94b290cd1df05001170c324500d71e0f5e80b60e5845ddc5                                                                                                                                                                                                                                                                              0.0s
 => => extracting sha256:35278b47ab256a3be461c75b8d8c2ae83ae6ea04cfb202e28c2195ebb0637427                                                                                                                                                                                                                                                                              0.0s
 => => extracting sha256:76a55975956e53808ab5cc933ce0212eb91e05162ac8a9c12523f17c78c615d7                                                                                                                                                                                                                                                                              0.0s
 => => extracting sha256:37eb6a1ed00f803e4608d3fe7cea489f6b8baef1565d39107edc9c023f39f442                                                                                                                                                                                                                                                                              0.0s
 => => extracting sha256:04263926308c0fd0d1f30d8303615bb1191baeeff9c3e4562434e5b8baa17ca1                                                                                                                                                                                                                                                                              0.0s
 => => extracting sha256:07a44844b644c629b273dccd3bf998437bd5b701d30024b914d4ee3bd59d86a3                                                                                                                                                                                                                                                                              0.1s
 => [internal] load build context                                                                                                                                                                                                                                                                                                                                      0.1s
 => => transferring context: 91.86kB                                                                                                                                                                                                                                                                                                                                   0.0s
 => [composer_cache 1/2] FROM docker.io/library/alpine:3.9                                                                                                                                                                                                                                                                                                             0.0s
 => => resolve docker.io/library/alpine:3.9                                                                                                                                                                                                                                                                                                                            0.0s
 => [composer_cache 2/2] RUN mkdir -p /cache && chmod 0777 /cache                                                                                                                                                                                                                                                                                                      0.4s
 => [spryker_app_dependencies 2/5] RUN apk add --no-cache openssl                                                                                                                                                                                                                                                                                                      2.0s
 => [spryker_app_dependencies 3/5] WORKDIR /data                                                                                                                                                                                                                                                                                                                       0.0s
 => [spryker_app_dependencies 4/5] COPY --chown=spryker:spryker composer.json composer.lock /data/                                                                                                                                                                                                                                                                     0.1s
 => [spryker_app_dependencies 5/5] RUN --mount=type=cache,target=/home/spryker/.composer/cache,from=composer_cache,source=/cache     composer install --no-interaction --optimize-autoloader --no-dev                                                                                                                                                                  2.2s
 => [spryker_docker_sdk 1/4] COPY --chown=spryker:spryker src /data/src                                                                                                                                                                                                                                                                                                0.1s
 => [spryker_docker_sdk 2/4] COPY --chown=spryker:spryker openssl /data/openssl                                                                                                                                                                                                                                                                                        0.1s
 => [spryker_docker_sdk 3/4] COPY --chown=spryker:spryker index.php /data                                                                                                                                                                                                                                                                                              0.0s
 => [spryker_docker_sdk 4/4] RUN chmod 755 /data/openssl/generate.sh                                                                                                                                                                                                                                                                                                   0.3s
 => exporting to image                                                                                                                                                                                                                                                                                                                                                 0.2s
 => => exporting layers                                                                                                                                                                                                                                                                                                                                                0.2s
 => => writing image sha256:bb836377ded7c1d6b3ca3cfdd426bc34a599168daf5666a4faddecdf2bd9dd76                                                                                                                                                                                                                                                                           0.0s
 => => naming to docker.io/library/spryker_docker_sdk                                                                                                                                                                                                                                                                                                                  0.0s
cp: deploy.yml: No such file or directory

GitHub Action - service "cli" is not running container #1

Which release, branch or hash of Docker SDK are you using?

1.49.4

Which operating system (platform/version/architecture) are you using?

Linux Ubuntu on GitHub Actions

What is the issue that you're experiencing?

Sometimes in ci jobs that use docker-sdk we have the following error:
service "cli" is not running container #1 /home/runner/work/project/project/docker/deployment/default/bin/service/database/postgres.sh: line 49: [: : integer expression expected

What are the steps to reproduce the issue?

  php-81-postgresql-integration-alpine:
    name: "PHP 8.1 / PostgreSQL / Integration / Alpine"
    runs-on: ubuntu-latest
    env:
      ...

    steps:
    ...

      - name: Run docker
        run: |
          git clone <docker-sdk latest>
          docker/sdk boot -v deploy.ci.integration.yml
          docker/sdk up -t << Here happened the error!
          docker/sdk testing console queue:worker:start --stop-when-empty
          docker/sdk testing codecept run -c codeception.ci.integration.yml

What is the expected result of these steps in the absence of the issue?

That docker sdk start

What is the actual result?

Github Workflow stopped with exit code 1

What possible solutions and/or workarounds for the issue do you see?

I don't know

Is there any other information that might be helpful?

I think not

Allow passing custom environment variables through sdk

What is the problem you are trying to solve by the feature?

Our pipelines build the frontend assets (yves) at multiple stages

  1. for acceptance tests (using "docker/sdk up")
  2. for deployment in cluster (using "docker/sdk export images")

I need to extend the frontend build process (webpack) so that it executes certain code (upload source maps to sentry) only if it's at a specific stage in our gitlab pipeline. My first idea was to define some env vars in the gitlab-ci.yml and access it through process.env. Unfortunately this doesn't work because the frontend build process lives in the docker/sdk and I can't pass custom env vars to it.

What is the solution do you propose?

There are two possible solutions

  1. allow passing through custom environment variables to the underlying call of the frontend build process
  2. provide information about the executed command (e.g. as env var) so that I know within the build process whether it has been triggered by "docker/sdk up" or by "docker/sdk export images"

While I doubt the former solution is already implemented (at least I couldn't find anything that looks promising), I'm still hoping the latter approach is somewhere hidden. Anyway I'd appreciate any hint how my problem could be solved.

What changes in deploy.yml format do you propose?

no idea

What changes in command line interface do you propose?

no idea either – maybe support of passing through custom env vars when calling "docker/sdk export images"

What alternatives have you considered?

I've thought about modifying the sdk though this is no real solution regarding the maintenance effort to keep it up-to-date.

Adjust sdk to work with mutagen-compose instead of mutagen compose

Which release, branch or hash of Docker SDK are you using?

master

Which operating system (platform/version/architecture) are you using?

macOS 11.6 Intel

What is the issue that you're experiencing?

Error: unknown command "compose" for "mutagen"

What are the steps to reproduce the issue?

  1. Update mutagen-beta to latest version
  2. Run docker/sdk up

What is the expected result of these steps in the absence of the issue?

Spryker starts without issues

What is the actual result?

SDK crushes with this error

What possible solutions and/or workarounds for the issue do you see?

Manual downgrade to version v0.13.0-beta2

Is there any other information that might be helpful?

Mutagen Compose

Mutagen Compose is now the default and only supported Compose/Mutagen integration mechanism. It is a separate, self-contained Compose implementation (accessed via the mutagen-compose command) based on Compose V2.

The aging Compose V1 integration that shipped in the v0.12 and v0.13 beta releases is now removed, with v0.13.0-beta4 containing the most recent version.

https://github.com/mutagen-io/mutagen/releases/tag/v0.13.0

Vulnerability CVE-2020-8244 found in the dependencies

Which release, branch or hash of Docker SDK are you using?

master

Which operating system (platform/version/architecture) are you using?

Any

What is the issue that you're experiencing?

Possible vulnerability found by GitHub Dependabot:

bl vulnerability found in …/dashboard/package-lock.json

CVE-2020-8244
high severity
Vulnerable versions: < 2.2.1
Patched version: 2.2.1
A buffer over-read vulnerability exists in bl <4.0.3, <3.0.1 and <2.2.1 which could allow an attacker to supply user input (even typed) that if it ends up in consume() argument and can become negative, the BufferList state can be corrupted, tricking it into exposing uninitialized memory via regular .slice() calls.

"docker/sdk up" Problem with MariaDB and BackOffice

Hello,

Have been following the official documentation to install the SDK via Docker but every time I get the following errors:

"ERROR 1130 (HY000): Host '192.168.0.11' is not allowed to connect to this MariaDB server"

Also all end-points are reachable except for the BackOffice Endpoint, I just get a 502 from nginx.

Has anyone had this problem before?
Thanks.

Key `sections` is not explained for installation recipes

I currently cannot find a documentation for the sections key of installation recipes.

How are we supposed to find out about

  • what these sections are for
  • what names we can use for sections
  • what names we have to use for sections (e.g., demodata, see #373)

?

Running

git grep -i sections

on current master yields

bin/command/compose/up.sh:5:Registry::Help::command -c "up [--build] [--assets] [--data] [--jobs]" "Builds and runs Spryker applications based on demo data. Re-executes the sections specified as options even if they have been executed before."
context/php/php.ini:31:; special sections cannot be overridden by user-defined INI files or
context/php/php.ini:32:; at runtime. Currently, [PATH=] and [HOST=] sections only work under
context/php/php.ini:34:; http://php.net/ini.sections
docs/07-deploy-file/02-deploy.file.reference.v1.md:71:For example, Docker images, containers and volume names start with a `namespace:` to avoid intersections between different deployments on a single host machine.
docs/07-deploy-file/02-deploy.file.reference.v1.md:96:For example, Docker images and volumes are tagged with a `tag:` to avoid intersections between different boots for a signle deployment on a single host machine. The tag can be set directly in the deploy file to ensure that all the boots of a deployment run with the same images and volumes.

Examples

See config/install/US/production.yml from spryker-shop/b2b-demo-shop:

sections:
    clean-oms:
        clear-oms-locks:
            command: "vendor/bin/console oms:clear-locks -vvv --no-ansi"

    diff:
        propel-migration-delete:
            command: "vendor/bin/console propel:migration:delete -vvv --no-ansi"

        propel-diff:
            command: "vendor/bin/console propel:diff -vvv --no-ansi"

        show_migrations:
            command: "ls -al ./src/Orm/Propel/Migration_*/*.php 2>/dev/null || true"

        propel-migrate:
            command: "vendor/bin/console propel:migrate -vvv --no-ansi"

        propel-migration-cleanup:
            command: "vendor/bin/console propel:migration:delete -vvv --no-ansi"

    scheduler-start:
        scheduler-setup:
            command: "vendor/bin/console scheduler:setup -vvv --no-ansi"
            stores: true

See config/install/docker.yml from spryker-shop/b2b-demo-shop:

sections:
    build:
        generate-transfers:
            command: 'vendor/bin/console transfer:generate'

        router-cache-warmup-yves:
            command: 'vendor/bin/yves router:cache:warm-up'

        router-cache-warmup-backoffice:
            command: 'vendor/bin/console router:cache:warm-up:backoffice'

        router-cache-warmup-backend-gateway:
            command: 'vendor/bin/console router:cache:warm-up:backend-gateway'

        twig-cache-warmup:
            command: 'vendor/bin/console twig:cache:warmer'

        navigation-cache-warmup:
            command: 'vendor/bin/console navigation:build-cache'

        rest-request-validation-cache-warmup:
            command: 'vendor/bin/console rest-api:build-request-validation-cache'

        propel-copy-schema:
            command: 'vendor/bin/console propel:schema:copy'

        propel-build:
            command: 'vendor/bin/console propel:model:build'

        generate-entity-transfer:
            command: 'vendor/bin/console transfer:entity:generate'

        generate-page-source-map:
            command: 'vendor/bin/console search:setup:source-map'

        translator-generate-cache:
            command: 'vendor/bin/console translator:generate-cache'

    build-production:
        excluded: true
        cache-class-resolver-build:
            command: 'vendor/bin/console cache:class-resolver:build'

    build-development:
        generate-transfers:
            command: 'vendor/bin/console transfer:generate'

        generate-transfer-databuilders:
            command: 'vendor/bin/console transfer:databuilder:generate'

        generate-auto-completion:
            command: 'vendor/bin/console dev:ide-auto-completion:generate'

        rest-api-generate-documentation:
            command: 'vendor/bin/console rest-api:generate:documentation'

    build-static:
        dependencies-install:
            command: 'vendor/bin/console frontend:project:install-dependencies'

        yves-install-dependencies:
            command: 'vendor/bin/console frontend:yves:install-dependencies'

        zed-install-dependencies:
            command: 'vendor/bin/console frontend:zed:install-dependencies'

    build-static-production:
        excluded: true
        yves-build-frontend:
            command: 'vendor/bin/console frontend:yves:build -e production'

        zed-build-frontend:
            command: 'vendor/bin/console frontend:zed:build -e production'


    build-static-development:
        yves-build-frontend:
            command: 'vendor/bin/console frontend:yves:build'

        zed-build-frontend:
            command: 'vendor/bin/console frontend:zed:build'



    scheduler-setup:
        jenkins-setup:
            command: 'vendor/bin/console scheduler:setup'

    scheduler-suspend:
        excluded: true
        jenkins-suspend:
            command: 'vendor/bin/console scheduler:suspend'

    scheduler-clean:
        excluded: true
        jenkins-clean:
            command: 'vendor/bin/console scheduler:clean'

    init-storages-per-store:
        queue-setup:
            command: 'vendor/bin/console queue:setup'
        setup-search-create-sources:
            command: 'vendor/bin/console search:setup:sources'

    init-storages-per-region:
        propel-copy-schema:
            command: 'vendor/bin/console propel:schema:copy'

        propel-postgres-compatibility:
            command: 'vendor/bin/console propel:pg-sql-compat'

        propel-migration-delete:
            command: 'vendor/bin/console propel:migration:delete'

        propel-tables-drop:
            command: 'vendor/bin/console propel:tables:drop'

        propel-diff:
            command: 'vendor/bin/console propel:diff'

        propel-migrate:
            command: 'vendor/bin/console propel:migrate'

        propel-migration-cleanup:
            command: 'vendor/bin/console propel:migration:delete'

        init-database:
            command: 'vendor/bin/console setup:init-db'

    demodata:
        import-demodata:
            command: 'vendor/bin/console data:import --config=data/import/local/full_${SPRYKER_REGION}.yml'

        update-product-labels:
            command: 'vendor/bin/console product-label:relations:update'

Generator docker won't build

Running docker/sdk bootstrap

will always end in:
++ docker build -t spryker_docker_sdk -f docker/generator/Dockerfile docker/generator [+] Building 1.1s (4/4) FINISHED => [internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 1.06kB 0.0s => [internal] load .dockerignore 0.0s => => transferring context: 48B 0.0s => resolve image config for docker.io/docker/dockerfile:experimental 0.9s => CACHED docker-image://docker.io/docker/dockerfile:experimental@sha256 0.0s failed to solve with frontend dockerfile.v0: failed to solve with frontend gateway.v0: exit code: 1

The reason is the usage of # syntax = docker/dockerfile:experimental because you want to use a cache mount. Sadly I don't know why it won't build locally. I have buildkit active in my docker daemon but it just won't work and I can't find any information on this issue on the net.

Docker version 19.03.2, build 6a30dfca03
Ubuntu 19.04

Ability to disable the creation of service containers

What is the problem you are trying to solve by the feature?

As of now, the docker/sdk enables developers to state individual services together with possible engines in the deploy.yml file. However, if one of these services (in our case the search service, so ElasticSearch) isn't required at all, there's currently no possibility to just leave out a service completly in the deploy.yml` file, resulting in the creation of redundant service containers.

What is the solution do you propose?

Adapt the generator so that it isn't required to state every possible service in the deploy.yml file. In the optimal case, one can just leave out a specific service (eg. the search service) and the docker/sdk is still able to generate a deployment without these services.

What changes in deploy.yml format do you propose?

As mentioned, in the optimal case the developer is able to leave out a specific service completly, assuming that the rest of the deploy.yml file also doesn't rely on the left out service (e.g. by specifying a namespace for a specific service, for example search, for a region of the store)

What changes in command line interface do you propose?

No need to.

What alternatives have you considered?

Of course, one can adjust the generated docker-compose.yml file manually in order to avoid the startup of a specific service container. However, this is a very "hacky" solution and one has to repeat the procedure after every new deployment generation.

Problems with Kibana

Which release, branch or hash of Docker SDK are you using?

Release 1.48.1 Master branch

Which operating system (platform/version/architecture) are you using?

MacOS Monterey 12.4 M1 Chip
Mutagen version 0.14.0
Compose version v2.5.0
Docker version v20.10.12

What is the issue that you're experiencing?

I'm trying to start Kibana 7.6.

What are the steps to reproduce the issue?

I added to services section in deploy.dev.yml

 kibana:
    engine: kibana
    version: 7.6
    endpoints:
        kibana.spryker.local:

What is the expected result of these steps in the absence of the issue?

What is the actual result?

When I open url kibana.spryker.local I see

Kibana server is not ready yet

Docker SDK sets wrong xDebug host ip environment variable when using WSL 2

Which release, branch or hash of Docker SDK are you using?

master (e97f950)

Which operating system (platform/version/architecture) are you using?

Windows and Docker on WSL2

What is the issue that you're experiencing?

When trying to debug according to the documentation, the IDE won't get in any connection.

What are the steps to reproduce the issue?

Follow the documentation to setup xDebug with Windows using Docker on WSL2.

What is the expected result of these steps in the absence of the issue?

PHPStorm is getting in a request from xDebug and the step debugger works.

What is the actual result?

PHPStorm is not getting any connection and debugging is impossible.

What possible solutions and/or workarounds for the issue do you see?

The reason is that Spryker sets the wrong xdebug.client_host (which is stored in SPRYKER_XDEBUG_HOST_IP environment variable). In my case it's setting 192.168.67.3 instead of 172.27.64.1.
That's because within docker.sh it jumps into the 'linux' section and executes the wrong command. Correct would be the command within 'windows' section. This platform variable is set in platform.sh. WSL2 outputs "Linux" when executing uname.
Therefore another way has to be found to figure out if WSL2 is used.

Workaround (but just a quick fix) is to manually execute tail -1 /etc/resolv.conf | cut -d' ' -f2 on WSL2 and replace xdebug.client_host in docker/deployment/default/context/php/debug/etc/php/debug.conf.d/69-xdebug.ini after bootstrapping.

NPM permission issue

There was an issue when I ran the command docker/sdk up about file and directories permissions with npm

service "cli" is not running container

Which release, branch or hash of Docker SDK are you using?

master

Which operating system (platform/version/architecture) are you using?

ubuntu-18.04 on GitHub Actions

What is the issue that you're experiencing?

The following error happens only sporadically, after a restart of the failed job it works without any issues.
In this case it was happen on Alpine, but it could also happen on Debian. Its totally sporadical.

https://github.com/elmerdigital/b2b-demo-shop/actions/runs/3540975943/jobs/5944669572
SCR-20221124-kiw

What are the steps to reproduce the issue?

I forked the current Spryker Demo Shop (https://github.com/elmerdigital/b2b-demo-shop).
The github CI which I use is the following (https://github.com/elmerdigital/b2b-demo-shop/blob/master/.github/workflows/ci.yml)

git clone https://github.com/spryker/docker-sdk.git ./docker
docker/sdk boot -v deploy.ci.acceptance.mariadb.yml
docker/sdk up -t
docker/sdk testing console queue:worker:start --stop-when-empty
docker/sdk testing codecept run -c codeception.acceptance.yml

What is the expected result of these steps in the absence of the issue?

A successful Github job

docker/sdk export images fails with an exception when building spryker release 202108.0

Which release, branch or hash of Docker SDK are you using?

Master

Which operating system (platform/version/architecture) are you using?

Ubuntu x86_64

What is the issue that you're experiencing?

docker/sdk export images fails with an exception (This command intended to be used non production environment only!)

What are the steps to reproduce the issue?

Clone the latest version of Spryker B2B (202108.0) and run below

  1. docker/sdk bootstrap deploy.spryker-b2b-staging.yml
  2. docker/sdk export images -t some-tag

What is the expected result of these steps in the absence of the issue?

Docker images are built

What is the actual result?

`

[cli-production 6/6] RUN vendor/bin/install -r docker -s build-development:
#13 1.168 ================================================================================
#13 1.168 Install docker environment
#13 1.168 ================================================================================
#13 1.168
#13 1.168
#13 1.168 Section build-development
#13 1.168
#13 1.168
Command generate-transfers [vendor/bin/console transfer:generate] (5.68s)
Command generate-transfer-databuilders [vendor/bin/console transfer:databuilder:generate] (1.45s)
Command generate-auto-completion [vendor/bin/console dev:ide-auto-completion:generate] (2.06s)
#13 10.36 Command rest-api-generate-documentation [vendor/bin/console rest-api:generate:documentation] (In progress...)
#13 11.18 Store: DE | Environment: docker-staging
#13 11.18 Store: DE | Environment: docker-staging
#13 11.18 Store: DE | Environment: docker-staging
#13 11.18 Generated Yves IDE auto-completion files
#13 11.18 Generated Zed IDE auto-completion files
#13 11.18 Generated Client IDE auto-completion files
#13 11.18 Generated Service IDE auto-completion files
#13 11.18 Can not find dev:ide-auto-completion:glue:generate in your project.
#13 11.18 You can fix this by adding the missing command to your project ConsoleDependencyProvider.
#13 11.18 Store: DE | Environment: docker-staging
#13 11.18 This command intended to be used non production environment only!
#13 11.18
#13 11.18 In CommandLineExecutable.php line 107:
#13 11.18
#13 11.18 Aborted install...
#13 11.18
#13 11.18
#13 11.18 install [-r|--recipe RECIPE] [-d|--dry-run] [-s|--sections SECTIONS] [-g|--groups GROUPS] [-x|--exclude EXCLUDE] [-e|--include-excluded INCLUDE-EXCLUDED] [-i|--interactive] [-b|--breakpoint] [-a|--ask-before-continue] [-l|--log] [--] []
#13 11.18`

What possible solutions and/or workarounds for the issue do you see?

Unsure

Is there any other information that might be helpful?

Yes. The above steps works for spryker previous release 202009.0-p1

Endpoint ports and default port 80 usage

80 => 80,

This will always bind the frondend container to port 80 which is not desirable. If I remove the default setting from the array everything goes as I desire. So I suggest to remove that entry to the array.

And it feels real strange to add all endpoints like "endpoint:80". In this case I mean the usage of double quotes around the yml keys. I would suggest to change this to a standard yml setting just below the endpoint name like

endpoint:
port: 8080

[macos] error when running docker/sdk up: invalid characters for a local volume name

Which release, branch or hash of Docker SDK are you using?

latest master: 3966b3b

Which operating system (platform/version/architecture) are you using?

macOS version 11.6.5(20G527)
2 GHz Quad-Core Intel Core i5
mutagen 0.14.0

project root path is /Users/firstname.lastname/git/project , where firstname, lastname and project only contain a-z chars

What is the issue that you're experiencing?

when running docker/sdk up, an error occurs:
Error response from daemon: create ././docker/deployment/default/env/cli: "././docker/deployment/default/env/cli" includes invalid characters for a local volume name, only "[a-zA-Z0-9][a-zA-Z0-9_.-]" are allowed. If you intended to pass a host directory, use absolute path

What are the steps to reproduce the issue?

docker/sdk boot deploy.dev.yml && docker/sdk up --build

What is the expected result of these steps in the absence of the issue?

local env starts

What is the actual result?

error occurs and containers are not started

What possible solutions and/or workarounds for the issue do you see?

none so far

Is there any other information that might be helpful?

docker-sdk clean does not remove all images

Which release, branch or hash of Docker SDK are you using?

1.30.0

Which operating system (platform/version/architecture) are you using?

Debian 10 / Jenkins

What is the issue that you're experiencing?

After running sequence boot; export images; clean - not all docker images are clean

What are the steps to reproduce the issue?

docker/sdk boot
docker/sdk export images (...)
docker/sdk clean
docker image ls

What is the expected result of these steps in the absence of the issue?

I expect docker/sdk clean to remove all images, so that no leftovers occupy disk space on a build system

What is the actual result?

One image is left after cleanup:

spryker_b2b_builder_assets                      1.0-9eec1e924352c98a7960f7275ed56b08ef7dd072   6839e66e1686        About a minute ago   1.55GB

What possible solutions and/or workarounds for the issue do you see?

As clean functionality is provided by docker-sdk, dangling image should be deleted by docker-sdk without workarounds

Currently using this to workaround the issue:

docker image rm `docker image ls | grep spryker_b2b_builder_assets | awk '{print $1":"$2}'`

[WSL2] Problem on docker/sdk up

Which release, branch or hash of Docker SDK are you using?

master

Which operating system (platform/version/architecture) are you using?

Windows 11, with WSL2

What is the issue that you're experiencing?

image

What are the steps to reproduce the issue?

I create a new enviroment following the instructions on Spryker documentation and when I use the command to star the enviroment it happens

What is the expected result of these steps in the absence of the issue?

star the enviroment

What is the actual result?

the error I showed on the print

What possible solutions and/or workarounds for the issue do you see?

change the source of the clone

Is there any other information that might be helpful?

down command returns error when bootstrapped with docker.dev.yml

Once started, containers can't be removed by running docker/sdk downcommand when boostraped with default deploy.dev.yml file. Tested on Ubuntu 18.04, docker 19.03.4, docker-compose 1.14.1 4667896b

Steps to reproduce:

  1. Follow all steps on Development Mode available at: https://documentation.spryker.com/installation/spryker_in_docker/getting-started-with-docker-201907.htm
  2. Run: $ docker/sdk down

Result:

$ docker/sdk down
*** DEVELOPMENT MODE
"docker rm" requires at least 1 argument.
See 'docker rm --help'.

Usage:  docker rm [OPTIONS] CONTAINER [CONTAINER...]

Remove one or more containers

Expected result:

Remove all containers.

Notes:

A quick fix was made by adding -r to stopCliContainer function at docker/development/default script, and editing genetor/src/templates/deploy.bash.twig. Problem is, the -r is not compatible with MacOS. May I make a pull request on this fix?

   -r, --no-run-if-empty
          If the standard input does not contain any nonblanks, do not
          run the command.  Normally, the command is run once even if
          there is no input.  This option is a GNU extension.

source: http://man7.org/linux/man-pages/man1/xargs.1.html

docker-sync on mac does not sync everything

Environment:

  • macOS 10.15.5
  • Docker version 19.03.8, build afacb8b
  • docker-sync 0.5.14
  • unison version 2.51.2 (ocaml 4.08.1)

use case:
we want to run grumphp on every pre-commit to check our requirements.
the grumphp looks kind of like that:

grumphp-config (minimized):

parameters:
    git_hook_variables:
        EXEC_GRUMPHP_COMMAND: docker/sdk cli php
    ignore_unstaged_changes: false
    process_timeout: 240
    tasks:
        composer:
            file: ./composer.json
        composer_script:
            script: "pre-commit"

        phplint:
        securitychecker:
            lockfile: ./composer.lock
        xmllint:
        yamllint:

this triggers docker/sdk cli php vendor/phpro/grumphp/bin/grumphp run before a commit is done (pre-commit-hook).
grumphp checks the git diff --staged.
unfortunately docker-sync does not sync the .git/objects/<dir> and thus grumphp cannot find the staged diff.

example error message:

Error while running git command: 
 'git' '--git-dir' '/data/.git' '--work-tree' '/data' 'diff' '-r' '-p' '-m' 
 '-M' '--full-index' '--staged' 
 fatal: unable to read 60dd77cb9f169ebb7794bef497dd72d6640cfaab 
 diff --git a/.dockerignore b/.dockerignore 
 new file mode 100644 
 index 0000000000000000000000000000000000000000..4fae21fdea7a50536276eea0fa9

[1]https://github.com/phpro/grumphp

UID issues

Which release, branch or hash of Docker SDK are you using?

1.30.0

Which operating system (platform/version/architecture) are you using?

Debian 10

What is the issue that you're experiencing?

Owner of files inside containers is not correctly set

What are the steps to reproduce the issue?

Build generator image (docker/sdk boot)
Check ownership of index.php

What is the expected result of these steps in the absence of the issue?

File ownership is adjusted to UID of current user

What is the actual result?

File ownership is set to UID=1000

What possible solutions and/or workarounds for the issue do you see?

--

Is there any other information that might be helpful?

https://github.com/spryker/docker-sdk/blame/master/generator/Dockerfile#L24
The line mentioned above gives an error - it’s ignored and doesn’t break docker build:

$ find / -user 1000 -exec chown -h spryker {} \ || true;
find: -exec requires an argument

Correct command is missing semicolon:

find / -user 1000 -exec chown -h spryker {} \; || true;

On first Install or if limits are incorrect give a shout out to increase swap and memory limits

What is the problem you are trying to solve by the feature?

On first install if you buzz past the setup you can get caught up in the build process with little direction if you haven't set the memory and swap limits correctly.

What is the solution do you propose?

add something to the boot output around here:

function Command::install() {
    local output=''
    if ! output=$(Registry::runInstallers); then
        Console::info 'Everything is properly installed. Nothing to do at the momemnt.' < also could fix this spelling error
        Console::info 'If this is your first time installing: did you set your swap limit to 2M?' << ? or something like that
        return "${TRUE}"
    fi
    ...

I don't know if Registry can detect first install and run, but you could log only on that, or more helpfully if you could detect the memory limits in docker and swap limits, then you could run the checker on that? either way...

If the system needs it then the system user should be aware of it

docker/sdk fails if umask isn't 022

Which release, branch or hash of Docker SDK are you using?

1.30.0

Which operating system (platform/version/architecture) are you using?

Linux Debian

What is the issue that you're experiencing?

docker/sdk fails in several places, when umask != 022

What are the steps to reproduce the issue?

umask 027
git clone <project>
git clone <docker_sdk>
docker/sdk boot deploy.yml && docker/sdk up

What is the expected result of these steps in the absence of the issue?

It should start the app

What is the actual result?

Some files inside container inherit permissions from source host, which means they aren't readable inside container.
First example (from possibly more) -

$ docker run -ti spryker_b2b_base_cli:1.0

$ ls -la /usr/local/etc/php/php.ini
-rw-r----- 1 root root 70953 Feb 18 16:34 php.ini

What possible solutions and/or workarounds for the issue do you see?

Permissions of files inside container should be controlled by build process and not rely on operating system's umask, which can be different (espacially on CI systems)

Is there any other information that might be helpful?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.