Comments (20)
dmytromykhailov
commented on July 21, 2024
1
Hi Ross,
Thank you for such detailed feedback. I need to take time and check your points, especially about naming the mentioned variables and how to make sure that the meaning is obvious. I'll get back as soon as I have updates.
Thank you once more!
Regards,
Dmytro
from docker-sdk.
rosscdh
commented on July 21, 2024
also suggest git clone ... --depth 1 as most users dont care about the git commit history for the sdk
from docker-sdk.
rosscdh
commented on July 21, 2024
maybe you could provide a example-deploy.yml that devs could cp to deploy.yml instead of forcing devs to compile their own ;)
from docker-sdk.
rosscdh
commented on July 21, 2024
cat docker/ci/deploy.yml > deploy.yml
[14:28:04] ross:docker-sdk git:(master*) $ docker/sdk up
Warning: GITHUB_TOKEN is not set but may be required.
[+] Building 1.7s (25/32)
=> [internal] load .dockerignore 0.0s
=> => transferring context: 35B 0.0s
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 35B 0.0s
=> resolve image config for docker.io/docker/dockerfile:experimental 0.9s
=> CACHED docker-image://docker.io/docker/dockerfile:experimental@sha256:888f21826273409b5ef5ff9ceb90c64a8f8ec7760da30d1ffbe6c3e2d323a7bd 0.0s
=> [internal] load metadata for docker.io/spryker/php:7.2 0.5s
=> [internal] load metadata for docker.io/library/alpine:3.9 0.0s
=> CANCELED [spryker_app_dependencies 1/5] FROM docker.io/spryker/php:7.2@sha256:438d8db0c2b72ff52685617f6d90af6b5f8d5df465f844ff9ff26356859fffb9 0.0s
=> => resolve docker.io/spryker/php:7.2@sha256:438d8db0c2b72ff52685617f6d90af6b5f8d5df465f844ff9ff26356859fffb9 0.0s
=> [internal] load build context 0.0s
=> => transferring context: 726B 0.0s
=> [composer_cache 1/2] FROM docker.io/library/alpine:3.9 0.0s
=> CACHED [composer_cache 2/2] RUN mkdir -p /cache && chmod 0777 /cache 0.0s
=> CACHED [spryker_app_dependencies 2/5] RUN mkdir -p /var/log/spryker && chown spryker:spryker /var/log/spryker 0.0s
=> CACHED [spryker_app_dependencies 3/5] WORKDIR /data 0.0s
=> ERROR [spryker_app_dependencies 4/5] COPY --chown=spryker:spryker composer.json composer.lock /data/ 0.0s
=> CACHED [spryker_app_dependencies 5/5] RUN --mount=type=cache,target=/home/spryker/.composer/cache,from=composer_cache,source=/cache bash -c 'if [ ! -z $GITHUB_TOKEN ]; then export COMPOSER_AUTH="{\"github-oauth\": {\"github.com\": \"${GITHUB_TOKEN}\"}}"; fi; composer install --no-interaction --optimize-autoloader' 0.0s
=> ERROR [spryker_app_base 1/8] COPY --chown=spryker:spryker src /data/src 0.0s
=> ERROR [spryker_app_base 2/8] COPY --chown=spryker:spryker config /data/config 0.0s
=> CACHED [spryker_app_base 3/8] COPY --chown=spryker:spryker *.php /data/ 0.0s
=> CACHED [spryker_app_base 4/8] RUN chmod 600 /data/config/Zed/*.key 0.0s
=> CACHED [spryker_app_base 5/8] RUN composer dump-autoload -o 0.0s
=> CACHED [spryker_app_base 6/8] RUN vendor/bin/install -r docker -s build 0.0s
=> ERROR [spryker_app_base 7/8] COPY --chown=spryker:spryker tests /data/tests 0.0s
=> CACHED [spryker_app_base 8/8] RUN vendor/bin/install -r docker -s build-development 0.0s
=> ERROR [spryker_app 1/10] COPY --chown=spryker:spryker data /data/data 0.0s
=> ERROR [spryker_app 2/10] COPY --chown=spryker:spryker public /data/public 0.0s
=> ERROR [spryker_app 3/10] COPY --chown=spryker:spryker frontend /data/frontend 0.0s
------
> [spryker_app_dependencies 4/5] COPY --chown=spryker:spryker composer.json composer.lock /data/:
------
------
> [spryker_app_base 1/8] COPY --chown=spryker:spryker src /data/src:
------
------
> [spryker_app_base 2/8] COPY --chown=spryker:spryker config /data/config:
------
------
> [spryker_app_base 7/8] COPY --chown=spryker:spryker tests /data/tests:
------
------
> [spryker_app 1/10] COPY --chown=spryker:spryker data /data/data:
------
------
> [spryker_app 2/10] COPY --chown=spryker:spryker public /data/public:
------
------
> [spryker_app 3/10] COPY --chown=spryker:spryker frontend /data/frontend:
------
failed to solve with frontend dockerfile.v0: failed to solve with frontend gateway.v0: rpc error: code = Unknown desc = failed to build LLB: failed to compute cache key: "/frontend" not found: not found
Failed again?
from docker-sdk.
rosscdh
commented on July 21, 2024
namespace: spryker_demo <-- this is really going to get confusing when you move to kube
from docker-sdk.
rosscdh
commented on July 21, 2024
what if i dont use github ...
COPY --chown=spryker:spryker composer.json composer.lock ${srcRoot}/
ARG GITHUB_TOKEN
RUN --mount=type=cache,target=/home/spryker/.composer/cache,from=composer_cache,source=/cache \
bash -c 'if [ ! -z $GITHUB_TOKEN ]; then export COMPOSER_AUTH="{\"github-oauth\": {\"github.com\": \"${GITHUB_TOKEN}\"}}"; fi; \
composer install --no-interaction --optimize-autoloader'
from docker-sdk.
rosscdh
commented on July 21, 2024
Generate ssl keys and certs and place them in the image?
from docker-sdk.
marek-obuchowicz
commented on July 21, 2024
what if i dont use github ...
then you see only a warning, that GITHUB_TOKEN may be required.
If you use however another git provider then you indeed need to configure composer credentials somehow, this is not covered by this SDK at the moment.
from docker-sdk.
tvaleriy
commented on July 21, 2024
Following this article should bring no problems - https://documentation.spryker.com/installation/spryker_in_docker/spryker-in-docker-201907.htm.
from docker-sdk.
dmytromykhailov
commented on July 21, 2024
Hi Ross,
docker/sdk bootstrap command looks for deploy.yml file, which is part of B2B/B2C demo shops repositories.
Example of deploy.yml files (and deploy.dev.yml if needed) can be found here:
- https://github.com/spryker-shop/b2b-demo-shop/blob/master/deploy.yml
- https://github.com/spryker-shop/b2c-demo-shop/blob/master/deploy.yml
They should be available in the PROJECT_ROOT directory.
from docker-sdk.
rosscdh
commented on July 21, 2024
Following this article should bring no problems - https://documentation.spryker.com/installation/spryker_in_docker/spryker-in-docker-201907.htm.
Thanks, that may be, but the README should provide everything a dev needs to get going, not reading some extra article thats not referenced or?
from docker-sdk.
rosscdh
commented on July 21, 2024
Hi Ross,
docker/sdk bootstrap command looks for deploy.yml file, which is part of B2B/B2C demo shops repositories.
Example of deploy.yml files (and deploy.dev.yml if needed) can be found here:
- https://github.com/spryker-shop/b2b-demo-shop/blob/master/deploy.yml
- https://github.com/spryker-shop/b2c-demo-shop/blob/master/deploy.yml
They should be available in the PROJECT_ROOT directory.
Thanks, yes that was clear but the root of the project should contain deploy.yml.example with the whole default suit of options so that I dont have to read 3 articles and figure out your DSL ;)
from docker-sdk.
rosscdh
commented on July 21, 2024
I see on https://documentation.spryker.com/installation/spryker_in_docker/docker_sdk/deploy-file-reference-version-1-201907.htm there is a "hidden" difficult to find example already. but why not just give it to the developer in the root of the repo ;)
also.. uppercase regions? why? lowercase everything unless you are camelCasing please..
from docker-sdk.
dmytromykhailov
commented on July 21, 2024
Hi Ross,
I see your point regarding having a single place of documentation.
We use README files to provide tools' descriptions, and not the whole solution or development approach. The starting point of learning about docker and any other functionality is Spryker Documentation Center. Detailed and full documentation of how to install and use tools lives there.
deploy.*.yml files are specific project implementation (B2B or B2C demo shops), which are used by docker-sdk.
Region declarations are just examples, and the upper case is used for visibility's sake. Of course, any naming approach can be used.
from docker-sdk.
rosscdh
commented on July 21, 2024
Thanks for taking the time, just some thoughts on dev workflows
-
documentation at the code needs to be in sync with the code; the README should give the dev all they need to get going, not needing to follow a chain of links which may change of their own accord and show 0 history of the change. Very rarely do you find a project that has a get-started that requires you to go off and read some other set of docs (that are not in the ?ref=HEAD//docs/ folder) for versioning reasons. This is a pretty standard thing.
-
then Id suggest providing a set of full fledged examples deploy.b2b.yml.example; that the developer can modify to suit. Forcing a external link that may (or may not) be up to date with the repo is... an anti-pattern. Also you introduce unnecessary hurdles for a dev to get started and you are trying to get market share right? less hurdles more winning.
-
fair enough, but it sounds like there are no validation schemas for the yaml?
from docker-sdk.
rosscdh
commented on July 21, 2024
also another one
PHP Fatal error: Uncaught Symfony\Component\Yaml\Exception\ParseException: A YAML file cannot contain tabs as indentation in "/data/deployment/project.yml" at line 10 (near " EU:"). in /data/vendor/symfony/yaml/Parser.php:159
using the deploy.yml from your examples?
** hint thats what happens when you copy paste from your docs ...
from docker-sdk.
rosscdh
commented on July 21, 2024
docker-compose shoould be treated as an expression of "state" and not make use of eNV vars the way you guys have chosen to.
Also things like depends_on is ok for dev (but really the point of loose-coupled microservices is... that they are loosely coupled right?)
if you are going to use this pattern then you DEF need to enforce a .env file in the root that loads automatically using something like https://github.com/vlucas/phpdotenv in phpland
from docker-sdk.
rosscdh
commented on July 21, 2024
Also where does one find docs on the various required env vars?
SPRYKER_LOG_DIRECTORY=''
SPRYKER_DOCKER_PREFIX=''
SPRYKER_DOCKER_TAG=''
SPRYKER_DOCKER_RUN_ARGUMENTS=''
SPRYKER_DOCKER_RUN_IMAGE=''
SPRYKER_REMOTE_DIR=''
COMPOSE_PROJECT_NAME=''
SPRYKER_LOG_DIRECTORY <-- docker == stdout no log directory (this is really bad if you require it)
${SPRYKER_DOCKER_PREFIX}_app:${SPRYKER_DOCKER_TAG} .... DOCKER_IMAGE_URI or DOCKER_IMAGE_FQDN is .. a better way than managing image variables, but really just make a reference and let the user use docker-compose.. thats what its there for.. give them sane defaults and dont force them to jump through the hoops of implicitness
SPRYKER_DOCKER_RUN_ARGUMENTS why are you enforcing this? its only for jenkins? but implies somethign do do with docker_run.. so.. docker-compose has the command and entrypoint keys which the name above implies something about... but no its just something to do with jenkins?
SPRYKER_DOCKER_RUN_IMAGE <--- ? only for jenkins
SPRYKER_REMOTE_DIR <--- what on earth is this? the deployment target dir? why is this required? you are distributing docker images?
COMPOSE_PROJECT_NAME <-- ok so.. "compose" (docker-compose, php-composer, redux-compose?
assets:
external: true
name: "${COMPOSE_PROJECT_NAME}_assets"
most of these values can be extracted from the deploy.yml file already or simply assumed.. its frustrating to have to jump through these hurdles before you can even deal with the subject matter.
from docker-sdk.
dmytromykhailov
commented on July 21, 2024
Hi Ross,
Let me update you with the status for the whole thread:
- We are going to improve the documentation in this release as well. It should solve some of the issues mentioned earlier.
- TAB characters in the documentation will be checked additionally.
- Variable names: definitely, we can do better here. I want to add that any information which is not public might be changed and is an internal implementation. By public I mean the following: deploy.*.yml files, API, documentation,
consoleapplication.
As this issue was about documentation initially so that it can be resolved.
Thank you for your feedback!
Regards,
Dmytro
from docker-sdk.
rosscdh
commented on July 21, 2024
Thanks for taking the feedback seriously, hopefully goes to shape a better
product
…On Thu, Nov 28, 2019 at 3:56 PM Dmytro Mykhailov ***@***.***> wrote:
Hi Ross,
Let me update with the status for the whole thread:
We are going to improve the documentation in this release as well. It
should solve some of the issues mentioned earlier.
TAB characters in the documentation will be checked additionally
Variable names: definitely, we can do better here. I want to add that any
information which is not public (e.g., deploy.*.yml files, API,
documentation, /console application) might be changed and is an internal
implementation.
As this issue was about documentation initially so that it can be resolved.
Thank you for your feedback!
Regards,
Dmytro
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#53?email_source=notifications&email_token=AADA6MVJIKEZFBTBVP5YYMDQV7L2JA5CNFSM4JNICBTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFM2RIY#issuecomment-559524003>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADA6MWXSLRYH2BKPJ2ABJDQV7L2JANCNFSM4JNICBTA>
.
from docker-sdk.
Related Issues (20)
- Section demodata is hard-coded, impossible to use meaningful name instead HOT 4
- Key `sections` is not explained for installation recipes HOT 2
- Docker SDK sets wrong xDebug host ip environment variable when using WSL 2 HOT 3
- GitHub Action - service "cli" is not running container #1 HOT 7
- Missing SPRYKER_FE_HOST & SPRYKER_FE_PORT in glue-storefront HOT 2
- docker/sdk reset command fails to run transfer:generate HOT 1
- On Linux systems 'docker-compose' is not found when 'docker compose' is installed HOT 2
- Cannot install Spryker using Docker SDK HOT 3
- Docker external cache sources HOT 1
- Wrong NodeJS version with debian plattform image (image.node.version is ignored) HOT 4
- Sporadical WebDriver timeout in acceptance tests HOT 5
- service "cli" is not running container HOT 3
- Allow passing custom environment variables through sdk HOT 2
- Adding custom services HOT 7
- bin/service/database/mysql.sh: line 48: [: : integer expression expected HOT 2
- Allow for JSON environment variables
- failed to get console during docker/sdk up HOT 1
- bash shebang is not platform agnostic
- Reduce verbosity of `composer install` in `application-production-dependencies` stage
- Mount files db in RAM
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from docker-sdk.