Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@mis98zb
Copy link

@mis98zb mis98zb commented Oct 27, 2021

  • If this is non-trivial feature, paste the links/URLs to the design doc.

  • Update the documentation to include this new feature.

  • Tests(including UT, IT, E2E) are added to verify the new feature.

  • If it's UI related, attach the screenshots below.

  • If this pull request closes/resolves/fixes an existing issue, replace the issue number. Closes #.

  • Update the CHANGES log.

@wu-sheng
Copy link
Member

Could you squash your commits? It seems too many.

@kezhenxu94 @hanahmily @JaredTan95 Could you take a look at this change? I am not familiar with this part of change.

@wu-sheng wu-sheng added TBD To be decided later, need more discussion or input. backend OAP backend related. docker Docker build scripts or images related labels Oct 27, 2021
@kezhenxu94 kezhenxu94 requested review from JaredTan95, hanahmily and kezhenxu94 and removed request for hanahmily October 27, 2021 02:52
Copy link
Member

@kezhenxu94 kezhenxu94 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This patch seems to be far from ready status, I think this kind of changes can be verified locally, @mis98zb

- name: Build docker image
run: |
make docker || make docker
make docker.push || make docker.push
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reminder, this should not be removed

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Docker buildx has an option '--push', with it docker will directly push the result docker image to the docker repository.
So as I remove this command.

However, I'm not sure if this version of docker image can be pushed to skywalking's repository.
After getting permission from your side, I'll add the '--push' option.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are various repositories. Check here, https://github.com/orgs/apache/packages?repo_name=skywalking

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Docker buildx has an option '--push', with it docker will directly push the result docker image to the docker repository. So as I remove this command.

Nice, if that's the case, we can remove this command but need to be able to switch the --push option in make command so we can build locally with pushing.

However, I'm not sure if this version of docker image can be pushed to skywalking's repository. After getting permission from your side, I'll add the '--push' option.

Yes we can push this new (arm) Docker images, with some prefixes or suffixes.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it.

And FYI, docker buildx does not add prefix or suffix on the tag...
It makes a manifest contains all specified platforms and push it to docker repository, so as one tag contains multiple architecture images.

Just like below:

TAG
11.0.11-jre
Last pushed3 months agobydoijanky
DIGEST                             OS/ARCH                         COMPRESSED SIZE 
50029fa89b65                  windows/amd64              5.88 GB
f416d2a5a8c2                   windows/amd64              2.54 GB
ccc36e4a72d1                   linux/amd64                    115.02 MB
2b8329599393                  linux/arm64/v8                112.8 MB

You can find this on https://registry.hub.docker.com/_/openjdk?tab=tags&page=1&name=11.0.11-jre

When docker client pull image, it will automatically choose the one with same arch as local.

Is this acceptable for skywalking?
Otherwise I can change to build one platform a time with different tags.
btw, personally I don't prefer this way... :P

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this only working for arm? Or apply to all x86?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I used '--platform linux/arm64,linux/amd64', it is working for both x86 and arm64.

If it is needed to separate x86 and arm64, I can change the makefile.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hanahmily @kezhenxu94 What do you prefer?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am feeling at least we should separate GHA repo push(x86 only) and release docker repo(x86 and arm) for official release.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pushing arm Docker images to GHCR may cost some storage but it's convenient if users want to try arm Docker images, I'm OK to separate or not

@mis98zb
Copy link
Author

mis98zb commented Oct 28, 2021

pushed to my docker hub repository, (^0^)v

https://hub.docker.com/repository/docker/mis98zb/ui/tags?page=1&ordering=last_updated

both linux/arm64 and linux/amd64 are avalible.

I'll have a simple test on my Raspberry Pi

@mis98zb mis98zb reopened this Oct 28, 2021
Comment on lines 72 to 78
ifeq ($(PUSH_DOCKER_IMAGE), true)
ifneq (DOCKER_REPOSITORY_TOKEN,)
DOCKER_LOGIN_CMD=docker login -u $(DOCKER_REPOSITORY_USER) -p $(DOCKER_REPOSITORY_TOKEN)
endif
DOCKER_PUSH_OPTION=--push
DOCKER_PUSH_CMD=docker push $(HUB)/$(3):$(TAG)
endif
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I personally don't want to have this because login can be EASILY done only once in user's PC and this is kind of out of our scope, also, requiring users to pass a secret into our script is not accepted somehow

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree. Let's not touch the privacy

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, you are right.

I add this optional login step is just because it be called by github workflow, which is run on a remote vm and I cannot login manually.
In fact, I wondered why there is no login step previously, and how does docker-publish workflow work...

if needed, I can move the login step to docker-publisher, or any other possible place.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mis98zb here is how we login in workflow

- name: Log in to the Container registry
uses: docker/[email protected]
with:
registry: ${{ env.HUB }}
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mis98zb Take this as a reference and remove the login step in our makefile.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok.

May I know where can I set these variables?
So as I can have a test on my forked repository...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are available in your GH Action in default.

Copy link
Member

@kezhenxu94 kezhenxu94 Oct 29, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok.

May I know where can I set these variables? So as I can have a test on my forked repository...

They are available by default, provided by GitHub Action. the only thing you need to do is to modify these lines to test in your forked repo (ghcr.io/apache/skywalking to ghcr.io/mis98zb/skywalking )

HUB: ghcr.io/apache/skywalking

if: github.repository == 'apache/skywalking'

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

got it.
thank you so much!!!

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I close this for testing on my forked repository, will reopen soon.

- name: Build docker image
run: |
make docker || make docker
make docker.push || make docker.push
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pushing arm Docker images to GHCR may cost some storage but it's convenient if users want to try arm Docker images, I'm OK to separate or not

@mis98zb
Copy link
Author

mis98zb commented Oct 29, 2021

docker push is still separated from build.
make docker only run build, and make docker PUSH_DOCKER_IMAGE=true will run build and push.

@mis98zb mis98zb closed this Oct 29, 2021
@mis98zb mis98zb reopened this Oct 29, 2021
@wu-sheng
Copy link
Member

wu-sheng commented Nov 2, 2021

Any update about this PR?

@mis98zb
Copy link
Author

mis98zb commented Nov 2, 2021

some E2E test failed with building test docker image (not the oap/ui image).
need more investigation...

btw, the oap/ui images pushed to docker hub can work on my local docker environment...

@wu-sheng
Copy link
Member

wu-sheng commented Nov 2, 2021

btw, the oap/ui images pushed to docker hub can work on my local docker environment...

Of course it can. What is the issue about this?

@mis98zb
Copy link
Author

mis98zb commented Nov 2, 2021

btw, the oap/ui images pushed to docker hub can work on my local docker environment...

Of course it can. What is the issue about this?

hehe, I mean, I've tested the pushed oap/ui images local and they started up without error.

however, E2E failed with biulding test docker image.
not sure if it is due to the base image change...

@wu-sheng
Copy link
Member

wu-sheng commented Nov 2, 2021

That is the point of e2e. Usually there are some pre-setup in your local env, which makes every steps working well. But running in the e2e env could expose these missing steps.

@mis98zb
Copy link
Author

mis98zb commented Nov 2, 2021

E2E.java succeeded meanwhile E2E.js failed.
It's hard to find out why....
maybe need some time to study E2E code...

@kezhenxu94
Copy link
Member

Hi @mis98zb , I've opened #8141 to address the review comments and polish the Makefile, can you please take a look?

@kezhenxu94
Copy link
Member

Closing in favor of #8141

@kezhenxu94 kezhenxu94 closed this Nov 17, 2021
@wu-sheng wu-sheng added this to the 8.9.0 milestone Nov 17, 2021
@wu-sheng wu-sheng removed the TBD To be decided later, need more discussion or input. label Nov 17, 2021
@mis98zb mis98zb deleted the master branch November 19, 2021 05:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backend OAP backend related. docker Docker build scripts or images related

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants