search

Azure / azure-cosmos-db-emulator-docker

This repo serves as hub for managing issues, gathering feedback, and having discussions regarding the Cosmos DB Emulator Docker.
https://learn.microsoft.com/en-us/azure/cosmos-db/how-to-develop-emulator?tabs=docker-linux%2Ccsharp&pivots=api-nosql
MIT License
145 stars 43 forks source link

Linux emulator fails on macOS M1 even with x64 virtualization #54

Open chriskuech opened 1 year ago

chriskuech commented 1 year ago

Understandably, you do not support M1 chips and it is questionable if supporting M1 chips is worth prioritizing; however, somehow the container fails on M1 even when using x64 virtualization, as demonstrated in #17.

At a minimum, can we have the container work with x64 emulation?

anton-bruilo commented 1 year ago

Please do something for start it on Mac M1 .. I see that another topics about that exists more than 1 year.

jonas-lomholdt commented 1 year ago

This would be an awesome addition since we are seeing more and more M1's as dev boxes.

tinydogio-joshua commented 1 year ago

I would also appreciate seeing this working. 🙏

theramzay commented 1 year ago

2+ years past since WWDC 2020. We're all need support for Apple silicon.

daveHylde commented 1 year ago

100% agree that the emulator should work on arm64. I've created this azure feedback post on the issue. Don't know if Microsoft care about it, but worth a shot. https://feedback.azure.com/d365community/idea/dc98013b-7348-ed11-a81b-000d3ae3db6e

chriskuech commented 1 year ago

FYI we ended up migrating off CosmosDB because of this

niels-busch-maersk commented 1 year ago

FYI we ended up migrating off CosmosDB because of this

One idea could be to use the MongoDB driver with CosmosDB and then replace emulator with MongoDB image.

Don't go down that route!

murbanowicz commented 1 year ago

@milismsft @mominag @aliuy

waszak commented 1 year ago

Try asking here https://learn.microsoft.com/en-us/answers/topics/azure-cosmos-db.html Maybe someone will look on this issue

tebeco commented 1 year ago

maybe @jongio know who to contact or existing workaround / replacement

jongio commented 1 year ago

@markjbrown would likely know

markjbrown commented 1 year ago

There's no workaround for this unfortunately. This is on our roadmap to deliver but I don't have any ETA.

tebeco commented 1 year ago

can you point out where the source is for the MSI hosted at https://aka.ms/cosmosdb-emulator that is in the Dockerfile

maybe someone might find out how to get update (replace/remove) all the servercore specifics to make it more XPlat ?

markjbrown commented 1 year ago

The emulator is not open source.

tebeco commented 1 year ago

should it be concidered to open source it ?

if not, should all the communication protocol be open / documented or is it already ? i'm thinking like the LSP

private impl could be kept private

It can only benefits everyone

markjbrown commented 1 year ago

Yes, I will definitely take that suggestion to the team.

Thank you!

Compusa commented 1 year ago

Please do whatever it takes to prioritise and get this resolved soon. Not having proper tool support is a show stopper.

Everything works perfectly in my development environment on the MacBook Pro M1, except the Azure Cosmos DB Emulator.

My current workaround is to run the Azure Cosmos DB Emulator on Parallels Desktop, but that workaround has a lot of disadvantages, and I wouldn't need Parallel Desktop if it wasn't for this...

redhatpeter commented 1 year ago

Please make sure to make it work for MacBook Pro M1. That will be a BIG help.

irby commented 1 year ago

Would love to see M1 support.

gc-6point6 commented 1 year ago

Not having M1 support is a big limitation, and it has definitely a major impact when it comes down to choosing a Cloud platform and/or Azure resource selection.

tinydogio-joshua commented 1 year ago

Agreed. Between this and not supporting mssql on aarch64 in docker, I'm concerned about proper development support of these products. Seems they're trying to rely on Docker supporting Rosetta (which is supposed to be a temporary/transition piece, not a something to rely on long term).

potatoqualitee commented 1 year ago

Oof, ran into this issue today. We need this for our Cosmos db app development as well.

Compusa commented 1 year ago

Oof, ran into this issue today. We need this for our Cosmos db app development as well.

Unfortunately the people responsible of this product doesn’t seem to care that much about this? Everything works just fine for me as .NET developer on a MacBook Pro M1 except the Azure Cosmos DB Emulator.

theramzay commented 1 year ago

Oof, ran into this issue today. We need this for our Cosmos db app development as well.

Unfortunately the people responsible of this product doesn’t seem to care that much about this? Everything works just fine for me as .NET developer on a MacBook Pro M1 except the Azure Cosmos DB Emulator.

Yep, same for me as dotnet/react developer. CosmosDB emulator the only one software on the world, that not runs at all on my arm64 Mac. It's looks insane for 2023. It not works even in latest Docker "Rosetta 2 in Linux" feature.

Compusa commented 1 year ago

The latest beta of Docker Desktop has a new feature for better support of running x86/64 binaries with Rosetta 2. Would this make it possible to run the Linux Emulator on M1 chips? I haven’t had the possibility to test this my self yet, so if anyone wants, please try it out and reach back here with the result please :)

More info about this can be found here: https://github.com/docker/roadmap/issues/384

theramzay commented 1 year ago

The latest beta of Docker Desktop has a new feature for better support of running x86/64 binaries with Rosetta 2. Would this make it possible to run the Linux Emulator on M1 chips? I haven’t had the possibility to test this my self yet, so if anyone wants, please try it out and reach back here with the result please :)

More info about this can be found here:

https://github.com/docker/roadmap/issues/384

Nope. I've tested it already. Emulator Just run & die immediately after start.

markjbrown commented 1 year ago

Hi folks. Thanks for all your comments.

As I mentioned back in December this is on our roadmap, but I don't have an ETA.

It might help if I explain how features get committed on our team. I think most folks here understand this, but I want to take a moment to explain to help set expectations and provide some solace to those who may not think we care or paying attention to this.

The Cosmos team (along with every service team in Azure) organizes feature work in 6-month semester that starts after a month of planning where work items are committed. The current semester started in October and runs through March. Despite Microsoft's size, feature teams are very lean. Items that are committed are done after careful resource planning to ensure we don't over commit, resulting in slips or dropped items. This means that even if we see intense demand for something after planning, (like this one here where the bulk of input occurred after the semester had started), it is unlikely we could take it on. This would often require dropping other committed work which could lead to a cascade of issues for downstream dependencies.

The planning for our next semester (April-October) will start sometime near the end of February next month. M1 support is among the list of features that will be reviewed for this upcoming semester. This GitHub issue here that you have been commenting and voting the feature up on, has been filed in support of the feature and is being followed.

We recognize and appreciate your continued interest and support for this. For people who are seeing this Issue for the first time, you are welcome to add your support as well. Once planning for our upcoming semester has concluded, myself or another on our team will revert back here on the outcomes.

Thanks again.

jonas-lomholdt commented 1 year ago

@markjbrown thanks for the insights on feature semesters. Don't sweat it - I'm just hoping for this to get committed to in the next semester, fingers crossed 🤞 And trying to create some buzz here to get the necessary attention 😉

solo812 commented 1 year ago

Would really love to see this. Tis a big deal for integration tests and regular development flows.

iescandon commented 1 year ago

My current workaround is to run the Azure Cosmos DB Emulator on Parallels Desktop, but that workaround has a lot of disadvantages, and I wouldn't need Parallel Desktop if it wasn't for this...

@Compusa could you explain how you got this running? I’ve been working on this for days and can’t seem to connect the code/SDK to the emulator. I am also using parallels.

theramzay commented 1 year ago

My current workaround is to run the Azure Cosmos DB Emulator on Parallels Desktop, but that workaround has a lot of disadvantages, and I wouldn't need Parallel Desktop if it wasn't for this...

@Compusa could you explain how you got this running? I’ve been working on this for days and can’t seem to connect the code/SDK to the emulator. I am also using parallels.

Hello, i'm using parallels too. This instruction works for me: https://learn.microsoft.com/en-us/azure/cosmos-db/local-emulator?tabs=ssl-netstd21#run-on-linux-macos

Compusa commented 1 year ago

My current workaround is to run the Azure Cosmos DB Emulator on Parallels Desktop, but that workaround has a lot of disadvantages, and I wouldn't need Parallel Desktop if it wasn't for this...

@Compusa could you explain how you got this running? I’ve been working on this for days and can’t seem to connect the code/SDK to the emulator. I am also using parallels.

Hello, i'm using parallels too. This instruction works for me: https://learn.microsoft.com/en-us/azure/cosmos-db/local-emulator?tabs=ssl-netstd21#run-on-linux-macos

Yes, this were the instructions I followed as well. Getting the certificates added correctly is crucial.

niklaswallerstedt commented 1 year ago

Now that Storage Explorer has preview support for ARM64 this is the missing piece for me to be on par with development on Windows.

Using a serverless Cosmos right now which is OK as a workaround but looking forward to have local support as well.

jjgriff93 commented 1 year ago

Big blocker for us right now as we have a local development suite that's unable to factor cosmos in for state storage - and most of our devs are on M chips

anton-bruilo commented 1 year ago

Big blocker for us right now as we have a local development suite that's unable to factor cosmos in for state storage - and most of our devs are on M chips

Yeah, that's a very big problem for all who works on M chips. I solved that on my side just installing windows virtual machine using Parallel and installed cosmos db emulator there. Also some steps for make it visible via local network for your macOs.

I know that it sounds terrible, but it works

Hope we will see fix from Microsoft soon

daveleee commented 1 year ago

I was able to build the docker image using this link but when I tried to run them it terminates immediately. I think it's because I have M1. Docker has an accelerator called rosetta for ARM architectures but didn’t work for the cosmos db emulator in my local env unfortunately. Another workaround except for a virtual machine can be having another windows laptop and access to that without firewall settings.

Btw would love to see M1 support soon!!!

li7vinov-denis commented 1 year ago

Big blocker for us right now as we have a local development suite that's unable to factor cosmos in for state storage - and most of our devs are on M chips

Yeah, that's a very big problem for all who works on M chips. I solved that on my side just installing windows virtual machine using Parallel and installed cosmos db emulator there. Also some steps for make it visible via local network for your macOs.

I know that it sounds terrible, but it works

Hope we will see fix from Microsoft soon

@anton-bruilo Could you please describe in which way you did that? I installed Parallels and Cosmos Emulator, even configured Firewall, but it's still not accessible from macOS

StefanHauser commented 1 year ago

Big blocker for us right now as we have a local development suite that's unable to factor cosmos in for state storage - and most of our devs are on M chips

Yeah, that's a very big problem for all who works on M chips. I solved that on my side just installing windows virtual machine using Parallel and installed cosmos db emulator there. Also some steps for make it visible via local network for your macOs. I know that it sounds terrible, but it works Hope we will see fix from Microsoft soon

@anton-bruilo Could you please describe in which way you did that? I installed Parallels and Cosmos Emulator, even configured Firewall, but it's still not accessible from macOS

@li7vinov-denis Same problem here. CosmosDB Emulator running on Windows 11 VM in Parallels but can't access the data explorer from my Mac. Tried a lot with Port Forwarding in Parallels, disabling Firewall on WIndows VM and also SSL certificate. Didn't get it running yet

theramzay commented 1 year ago

I don't know how, but it just works for me. I've used manual from Microsoft docs for parallels on my M1 Pro MacBook Pro and CosmosDB then accessible on host by VM's IP:Port

StefanHauser commented 1 year ago

@ramzzzay Thanks for responding. So just for clarification:

  1. I ran on my Windows 11 VM .\Microsoft.Azure.Cosmos.Emulator.exe /AllowNetworkAccess /Key=C2y6yDjf5/R+ob0N8A7Cgv30VRDJIWEHLM+4QDU5DE2nQ9nDuVTqobD4b8mGGyPMbIZnqyMsEcaGQy67XIw/Jw==. CosmosDB Emulator is up and running on the VM:

    image

  2. I am running Parallels in Shared Networking and have this IP for my VM:

    image

  3. netsh firewall show state on Windows VM shows that ports 8081 and 8900 are open on every network interface.

  4. Ping to IP address 10.211.55.3 from my mac works but nc to port 8081 doesn't.

  5. Also, Cosmos Data Explorer doesn't load when trying to open https://10.211.55.3:8081/_explorer/index.html

Is there anything obvious I have missed? Any hint is highly appreciated! :)

li7vinov-denis commented 1 year ago

@StefanHauser I have same behavior.

  1. Network is shared
  2. Ports are open
  3. Certificate is imported
  4. Cosmos Data Explorer doesn't connect both via direct IP and associated host in hosts file
theramzay commented 1 year ago

@StefanHauser

  1. on windows11 parallels machine Screenshot 2023-04-17 at 15 33 41
  2. then on macOS host https://10.211.55.4:8081/_explorer/index.html image
daveleee commented 1 year ago

@ramzzzay Can I ask which versions of Parallels, MacOS(M1?) and so on? I did the same thing and was not able to access from my Mac

theramzay commented 1 year ago

@daveleee macOS 13.3.1, m1 pro, parallels 18.1.1, win11arm64

johnborges commented 1 year ago

Has anyone tried this via UMT?

daveleee commented 1 year ago

@ramzzzay Thank you for the answer. Except for m1 pro all version is the same as mine. Did you try something additional other than following steps?

Also could you describe the way how you opened the port 8081 on mac?

LukasKlein97 commented 1 year ago

Same Issue like @daveleee and @StefanHauser M1 Mac Pro 13.2.1 , Win11

theramzay commented 1 year ago

@daveleee i don't know how to open ports on mac, literally done nothing for this. For certificate i've used Microsoft docs manual.
I've attached settings of firewall in macOS and network tab in parallels.

image image image
imkarrer commented 1 year ago

Thanks for the transparency in your update @markjbrown, it is very insightful. Can you share if capacity for m1 support has been allocated in your current semester? I think the entire community understands, but we also have to explain to our internal users whats going on / if we should chase down other potential solutions.

Its a double whammy; non windows environment and not really billable. I understand why from a ROI perspective it might not seem prudent for Microsoft to prioritize this even if customers are asking for it year over year. However, I will state that our engineers can develop at greater speed with a local cosmos and therefore will have more time to write more tests that can then promoted into environments backed by serverless cosmos.

If you build it, they will come :). Thanks again.

markjbrown commented 1 year ago

Hi @imkarrer

Unfortunately this did not land as committed for this semester. I'm sorry I wish I had better news to share.

I will point out that this thread on GitHub has not gone unnoticed. We are working to make adjustments and hope to be able to land this as a committed feature in our next semester.

The length of time to get movement on this is also not just about whether it's billable or not. Our customer is a developer. Basically all of you here. We recognize that if you can't do your job or if we make using the service difficult or don't remove friction, we hurt ourselves. This is just one of those things where we're forced to make a painful decision. This frustrates us as well.

Again my sincere apologies. Thanks for hanging with us. I hope some or all of you are able to leverage the workaround above.

Myself or someone on our team will come back here to give you an update when we close on our next semester planning.

Thanks.