Support for Mac M1 about docker-sdk HOT 21 CLOSED

I got a response in the slack channel that it was postponed to Q1 2022

from docker-sdk.

Hi @thettler,

Thanks for the last update, it's getting closer on my M1 mac, but after applying the changes you mentioned, and after waiting for a while, i get the following error message:

Service broker is not running. Please check the name.

Do you know how to fix this issue?

Thanks in advance,

Camilo

from docker-sdk.

To me personally a few weeks ago it was confirmed that it was not postponed, but at this point a day before the end of Q1 I actually have doubts that by tomorrow support for M1 can be officially released.

In the end it does not matter if it's one or X weeks later. It's more about setting right expectations from spy team towards partners. As it was promised for 21/Q4 then 22/Q1, now its Q2, then maybe Q3 and so on... This is a major issue blocking me and my colleagues from switching to M1 macbooks.

I am just trying to make this issue somehow more visible and maybe give it higher priority in your pipeline. Thanks

from docker-sdk.

Same issue on fresh M1 MacBook Air with Docker for Silicone, as well. Would be great if someone could pick this up.

from docker-sdk.

Hello. Any news? Could you please answer when this problem can be resolved for MAC with M1 ?

Hello, @DmitriyDem and sorry for the log response time.

The support of the MAC with M1 is planned until the end of the Q4.

If this is a blocker for you, you can take a look at the experimental branch.

from docker-sdk.

Ping (🍎 M1)

soon comes the end of Q2

any news about the official support for M1?

the current status - In QA.
Yes, you are absolutely right, it was planned for the end of Q1 but unfortunately it has been delayed due to several critical issues.

from docker-sdk.

Hi, @alexanderM91
it seems like this official support for M1 requires elasticsearch version >7.6. That's likely to be a major problem for us that are still on version 5.6.

Why was this requirement introduced how can we continue using 5.6? AFAIK the experimental M1 branch worked just fine with the older version...

Also, I hope you're not planning to remove the experimental branch anytime soon - doing that might prevent some people from working with Spryker on their M1 completely.

from docker-sdk.

I tinkered araound a little bit more and have some new insights and got it nearly running.

You can remove the warning form the bootstrap command if you add --platform linux/amd64 to bin/command/install/bootstrap.sh:111. This will pull the correct Image.

in/command/install/bootstrap.sh:111

    docker run -i --rm "${userToRun[@]}" \
        -e SPRYKER_DOCKER_SDK_PLATFORM="${_PLATFORM}" \
        -e SPRYKER_DOCKER_SDK_DEPLOYMENT_DIR="${DESTINATION_DIR}" \
        -e VERBOSE="${VERBOSE}" \
        --platform linux/amd64 \
        -v "${tmpDeploymentDir}":/data/deployment:rw \
        spryker_docker_sdk

To Fix theupcommand you have to modify bin/sdk/images/common.sh and also add some --platform linux/amd64

# ...
function Images::_buildApp() {

    local -a sshArgument=()
    local folder=${1}
    local baseAppImage="${SPRYKER_DOCKER_PREFIX}_base_app:${SPRYKER_DOCKER_TAG}"
    local appImage="${SPRYKER_DOCKER_PREFIX}_app:${SPRYKER_DOCKER_TAG}"
    local localAppImage="${SPRYKER_DOCKER_PREFIX}_local_app:${SPRYKER_DOCKER_TAG}"
    local runtimeImage="${SPRYKER_DOCKER_PREFIX}_run_app:${SPRYKER_DOCKER_TAG}"
    local baseCliImage="${SPRYKER_DOCKER_PREFIX}_base_cli:${SPRYKER_DOCKER_TAG}"
    local cliImage="${SPRYKER_DOCKER_PREFIX}_cli:${SPRYKER_DOCKER_TAG}"
    local runtimeCliImage="${SPRYKER_DOCKER_PREFIX}_run_cli:${SPRYKER_DOCKER_TAG}"

    if [ -n "${SSH_AUTH_SOCK_IN_CLI}" ]; then
        sshArgument=('--ssh' 'default')
    fi

    Images::_prepareSecrets
    Registry::Trap::addExitHook 'removeBuildSecrets' "rm -f ${SECRETS_FILE_PATH}"

    Console::verbose "${INFO}Building Application images${NC}"

    docker build \
        -t "${baseAppImage}" \
        -f "${DEPLOYMENT_PATH}/images/common/application/Dockerfile" \
        --progress="${PROGRESS_TYPE}" \
        --build-arg "SPRYKER_PLATFORM_IMAGE=${SPRYKER_PLATFORM_IMAGE}" \
        --build-arg "SPRYKER_LOG_DIRECTORY=${SPRYKER_LOG_DIRECTORY}" \
        --build-arg "SPRYKER_PIPELINE=${SPRYKER_PIPELINE}" \
        --build-arg "APPLICATION_ENV=${APPLICATION_ENV}" \
        --build-arg "SPRYKER_DB_ENGINE=${SPRYKER_DB_ENGINE}" \
        --build-arg "KNOWN_HOSTS=${KNOWN_HOSTS}" \
        --build-arg "SPRYKER_BUILD_HASH=${SPRYKER_BUILD_HASH:-"current"}" \
        --build-arg "SPRYKER_BUILD_STAMP=${SPRYKER_BUILD_STAMP:-""}" \
        "${DEPLOYMENT_PATH}/context" 1>&2

    docker build \
        -t "${appImage}" \
        -f "${DEPLOYMENT_PATH}/images/${folder}/application/Dockerfile" \
        "${sshArgument[@]}" \
        --secret "id=secrets-env,src=$SECRETS_FILE_PATH" \
        --progress="${PROGRESS_TYPE}" \
        --build-arg "SPRYKER_PARENT_IMAGE=${baseAppImage}" \
        --build-arg "SPRYKER_DOCKER_PREFIX=${SPRYKER_DOCKER_PREFIX}" \
        --build-arg "SPRYKER_DOCKER_TAG=${SPRYKER_DOCKER_TAG}" \
        --build-arg "USER_UID=${USER_FULL_ID%%:*}" \
        --build-arg "DEPLOYMENT_PATH=${DEPLOYMENT_PATH}" \
        --build-arg "SPRYKER_PIPELINE=${SPRYKER_PIPELINE}" \
        --build-arg "APPLICATION_ENV=${APPLICATION_ENV}" \
        --build-arg "SPRYKER_DB_ENGINE=${SPRYKER_DB_ENGINE}" \
        --build-arg "SPRYKER_COMPOSER_MODE=${SPRYKER_COMPOSER_MODE}" \
        --build-arg "SPRYKER_COMPOSER_AUTOLOAD=${SPRYKER_COMPOSER_AUTOLOAD}" \
        --build-arg "SPRYKER_BUILD_HASH=${SPRYKER_BUILD_HASH:-"current"}" \
        --build-arg "SPRYKER_BUILD_STAMP=${SPRYKER_BUILD_STAMP:-""}" \
        --platform linux/amd64 \
        . 1>&2

    docker build \
        -t "${localAppImage}" \
        -t "${runtimeImage}" \
        -f "${DEPLOYMENT_PATH}/images/common/application-local/Dockerfile" \
        --progress="${PROGRESS_TYPE}" \
        --build-arg "SPRYKER_PARENT_IMAGE=${appImage}" \
        --platform linux/amd64 \
        "${DEPLOYMENT_PATH}/context" 1>&2

    if [ -n "${SPRYKER_XDEBUG_MODE_ENABLE}" ]; then
        docker build \
            -t "${runtimeImage}" \
            -f "${DEPLOYMENT_PATH}/images/debug/application/Dockerfile" \
            --progress="${PROGRESS_TYPE}" \
            --build-arg "SPRYKER_PARENT_IMAGE=${localAppImage}" \
            --platform linux/amd64 \
            "${DEPLOYMENT_PATH}/context" 1>&2
    fi

    Console::verbose "${INFO}Building CLI images${NC}"

    docker build \
        -t "${baseCliImage}" \
        -f "${DEPLOYMENT_PATH}/images/common/cli/Dockerfile" \
        --progress="${PROGRESS_TYPE}" \
        --build-arg "SPRYKER_PARENT_IMAGE=${localAppImage}" \
        --platform linux/amd64 \
        "${DEPLOYMENT_PATH}/context" 1>&2

    docker build \
        -t "${cliImage}" \
        -t "${runtimeCliImage}" \
        -f "${DEPLOYMENT_PATH}/images/${folder}/cli/Dockerfile" \
        "${sshArgument[@]}" \
        --secret "id=secrets-env,src=$SECRETS_FILE_PATH" \
        --progress="${PROGRESS_TYPE}" \
        --build-arg "SPRYKER_PARENT_IMAGE=${baseCliImage}" \
        --build-arg "DEPLOYMENT_PATH=${DEPLOYMENT_PATH}" \
        --build-arg "SPRYKER_PIPELINE=${SPRYKER_PIPELINE}" \
        --build-arg "SPRYKER_BUILD_HASH=${SPRYKER_BUILD_HASH:-"current"}" \
        --build-arg "SPRYKER_BUILD_STAMP=${SPRYKER_BUILD_STAMP:-""}" \
        --platform linux/amd64 \
        .  1>&2

    if [ -n "${SPRYKER_XDEBUG_MODE_ENABLE}" ]; then
        docker build \
            -t "${runtimeCliImage}" \
            -f "${DEPLOYMENT_PATH}/images/debug/cli/Dockerfile" \
            --progress="${PROGRESS_TYPE}" \
            --build-arg "SPRYKER_PARENT_IMAGE=${cliImage}" \
            --platform linux/amd64 \
            "${DEPLOYMENT_PATH}/context" 1>&2
    fi

    Registry::Trap::releaseExitHook 'removeBuildSecrets'
}
# ...

Unfortunately there is a qemu bug in the elasticsearch image witch prevents spryker from fully working.
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
docker/for-mac#5123

from docker-sdk.

Hi all,

I can confirm the same error as @camilou when using the workaround from @thettler with my MacBook Pro (13-inch, M1, 2020).

Recreating spryker_item_b2b_dev_gateway_1 ... done
Restarting spryker_item_b2b_dev_gateway_1  ... done
Restarting spryker_item_b2b_dev_frontend_1 ... done
Service `broker` is not running. Please check the name. 

Any ideas how to solve this?

Also are there plans to provide images for linux/arm64 ?

from docker-sdk.

Anyone fixed this yet? Or got around that issue?

from docker-sdk.

Hello. Any news? Could you please answer when this problem can be resolved for MAC with M1 ?

from docker-sdk.

Thanks for response!✌️

from docker-sdk.

Hi there..
Any news if the planned support for M1 will arrive these days or if there are significant delays?

from docker-sdk.

Hi,
any news on this ?

from docker-sdk.

Q1 is almost over, any updates on this? Shall we wait 2 more days or it got delayed to Q2? Thanks.

from docker-sdk.

To me personally a few weeks ago it was confirmed that it was not postponed, but at this point a day before the end of Q1 I actually have doubts that by tomorrow support for M1 can be officially released.

from docker-sdk.

To me personally a few weeks ago it was confirmed that it was not postponed, but at this point a day before the end of Q1 I actually have doubts that by tomorrow support for M1 can be officially released.

In the end it does not matter if it's one or X weeks later. It's more about setting right expectations from spy team towards partners. As it was promised for 21/Q4 then 22/Q1, now its Q2, then maybe Q3 and so on... This is a major issue blocking me and my colleagues from switching to M1 macbooks.

I am just trying to make this issue somehow more visible and maybe give it higher priority in your pipeline. Thanks

I'm not an internal member of the Spryker, so I can only tell you what was communicated to me.

In any case you are completely correct. Although I've been using Spryker Docker SDK with M1 for over a month now and have absolutely no issues whatsoever.

So one thing is the official support and we are all right in complaining, secondly this is not a block at the moment because as I said you can work with it without any problem.

p.s.: of course there is a guide (slack threads...) and some aspects to take into account for the project to be compatible etc...

from docker-sdk.

Ping (🍎 M1)

soon comes the end of Q2

any news about the official support for M1?

from docker-sdk.

I just Seen that in Release 1.47.0 has been released the support for ARM Architecture.
…but I see also that experimental branch ‘apple-m1-adjustement’ is still alive and not merged.
I asked now me self: is release 1.47.0 also for M1 ARM Provessor or not?
I am a little bit confused 🫤 @alexanderM91

from docker-sdk.

Hi,
good news, we have officially released support of ARM architecture (M1)

Small guidance how to make your project up and running with ARM architecture (M1) - https://docs.spryker.com/docs/scos/dev/technical-enhancement-integration-guides/switch-to-arm-architecture-m1-chip.html.

Hi @ynnoig,
apple-m1-adjustement it was a temporary solution and it will not be merged into the master branch.
Please use the latest master and attached guidance.

from docker-sdk.

Hi @namikk,
The current images weren't provided due to the fact of their EOL - https://www.elastic.co/support/eol BUT to make your migration smooth, they are already prepared - ES (5.6, 6.8) and KIbana (5.6, 6.8) and will be tested soon.
As a suggestion please consider migration.

No, I am not planning to remove a temporary branch in the nearest future due to the migration process (approx. one month) but it will not be supported anymore.

from docker-sdk.