Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please support PowerShell core on SDK images #360

Closed
AceHack opened this issue Jan 22, 2018 · 61 comments

Comments

Projects
None yet
@AceHack
Copy link

commented Jan 22, 2018

Please add powershell core on both linux and windows SDK images

@AceHack

This comment has been minimized.

Copy link
Author

commented Jan 23, 2018

Please also make this the default cmd handler in the image

@MichaelSimons

This comment has been minimized.

Copy link
Collaborator

commented Jan 23, 2018

We would like to hear more requests from the community on this before making a change. Making the Powershell the default SHELL would not be something we would consider as we feel it is not what the Linux community would expect.

@AceHack

This comment has been minimized.

Copy link
Author

commented Jan 24, 2018

Would it be possible to create an alternative tag/image that has PowerShell as the default? This would make it so I would not have to create my own base image for all my apps that does the same. Thanks.

@MichaelSimons

This comment has been minimized.

Copy link
Collaborator

commented Jan 24, 2018

If there is a strong demand for such images then it would be something we would consider. In general we try to limit the number of images permutations as deciphering the differences between all of the images can be difficult.

@AceHack

This comment has been minimized.

Copy link
Author

commented Jan 24, 2018

Just to give a little context, I use PowerShell so I can create one Dockerfile that works on both Windows and Linux containers even though in many cases the builds are complicated and require scripting. Before I had to maintain two different Dockerfiles and script the same actions in two different languages. Thanks.

@richlander

This comment has been minimized.

Copy link
Member

commented Jan 24, 2018

Assume we did add powershell to our SDK images. Why would you need the default shell to be powershell in the dotnet images to enable your scenario?

@AceHack

This comment has been minimized.

Copy link
Author

commented Jan 24, 2018

Because on Windows the executable name is powershell and on Linux it’s pwsh. So at a minimum I would have to have two base images that set the default shell accordingly and then the multiarch tag. Then all my services would need to reference the multiarch tag.

@richlander

This comment has been minimized.

Copy link
Member

commented Jan 24, 2018

I can see how that would be nice, but it's well within your capability to solve. It's not so challenging that it's worth us creating a whole series of additional images to update. We'd have to create ~20 new images to make that work.

@AceHack

This comment has been minimized.

Copy link
Author

commented Jan 25, 2018

If you add powershell to the base images for the sdk but don't make it the default could you run the following

#!/bin/bash
ln -s /usr/bin/pwsh /usr/bin/powershell

This will alias pwsh as powershell and I should be able to set the default myself in a way that would work on both OSs in a single docker file.

Thanks.

@richlander

This comment has been minimized.

Copy link
Member

commented Jan 26, 2018

That may be a middle ground.

First, we need more requests to add powershell. This request is the first one I am aware of.

@itz1508

This comment has been minimized.

Copy link

commented Jan 26, 2018

@yuhuazhong

This comment has been minimized.

Copy link

commented Jan 26, 2018

I second @AceHack on supporting powershell on Linux. It just enable a lot of possibility for development. It also help us make a stronger business case to adopt container technology in our company.

@kz1000fan

This comment has been minimized.

Copy link

commented Jan 26, 2018

Same here...this is a much-needed feature for consistency of experiences.

@ericrini

This comment has been minimized.

Copy link

commented Jan 26, 2018

I would like this feature too.

@tkring

This comment has been minimized.

Copy link

commented Jan 26, 2018

I vote for this feature. It will help our company adopt AKS.

@AceHack

This comment has been minimized.

Copy link
Author

commented Jan 28, 2018

@richlander looking at PowerShell core 6.0.1 it's even called pwsh when installed on windows nanoserver-1709 so just including it would be great! Thanks.

@richlander

This comment has been minimized.

Copy link
Member

commented Jan 28, 2018

Anyone know how big it is once installed?

@AceHack

This comment has been minimized.

Copy link
Author

commented Jan 28, 2018

I'm working on creating a base image myself for nanoserver-1709 and stretch, I'll send the link once I'm done.

@richlander

This comment has been minimized.

Copy link
Member

commented Jan 28, 2018

Please do send the link. I'm most interested in what docker history says, so please (for now) add powshell by itself so that it creates a distinct layer.

@AceHack

This comment has been minimized.

Copy link
Author

commented Jan 28, 2018

@richlander I have not made the multi-arch tag yet, I'll do that tomorrow but here they are on docker hub.
https://hub.docker.com/r/acehack/dotnet/tags/

Also here are the source Dockerfiles.
https://github.com/AceHack/dotnet-docker-powershell

If you want me to make any changes to help you out just let me know.
Thanks.

@MichaelSimons

This comment has been minimized.

Copy link
Collaborator

commented Jan 29, 2018

Adding the following to https://github.com/dotnet/dotnet-docker-nightly/blob/master/2.1/sdk/stretch/amd64/Dockerfile results in a layer that is 114 MB.

RUN apt-get update \
    && apt-get install -y --no-install-recommends \
        apt-transport-https \
    && curl https://packages.microsoft.com/keys/microsoft.asc | apt-key add - \
    && sh -c 'echo "deb [arch=amd64] https://packages.microsoft.com/repos/microsoft-debian-stretch-prod stretch main" > /etc/apt/sources.list.d/microsoft.list' \
    && apt-get update \
    && apt-get install -y --no-install-recommends \
        powershell=6.0.0-1.debian.9 \
    && rm -rf /var/lib/apt/lists/*
@sonalgpatil

This comment has been minimized.

Copy link

commented Jan 29, 2018

I would like this feature too.

1 similar comment
@t-sup

This comment has been minimized.

Copy link

commented Jan 29, 2018

I would like this feature too.

@AceHack

This comment has been minimized.

Copy link
Author

commented Jan 29, 2018

@MichaelSimons you could further reduce the size by removing the .NET core version that comes bundled with PowerShell. I've requested the PS team makes this a first class scenario.
PowerShell/PowerShell#6058 (comment)

@scottcollins

This comment has been minimized.

Copy link

commented Jan 29, 2018

I would also like this feature

@stdistef

This comment has been minimized.

Copy link

commented Jan 29, 2018

I would like this feature too

@kalenwatermeyer

This comment has been minimized.

Copy link

commented Jan 29, 2018

Please add this feature

@Huesie

This comment has been minimized.

Copy link

commented Jan 29, 2018

+1 for x-plat targeting - please add this

@achrjulien

This comment has been minimized.

Copy link

commented Jul 26, 2018

We are also missing the ability to use our .ps1 scripts here

@panmanphil

This comment has been minimized.

Copy link

commented Aug 11, 2018

also here, would love an option to use powershell instead of cmd as default, mostly for downloading, unpacking and installs, but also for init scripts that would have to pull in configuration that sort of thing to setup the application

@yamac-kurtulus

This comment has been minimized.

Copy link

commented Aug 27, 2018

Are people even using cmd?

@fabioimpe

This comment has been minimized.

Copy link

commented Oct 24, 2018

Is there any chance to use powershell inside the dotnet image? At least for the sdk version, thank you.

@achrjulien

This comment has been minimized.

Copy link

commented Oct 24, 2018

@fabioimpe On our side, we moved everything to Python and stopped using powershell. It makes life much easier, even though we had to re-write our scripts

@sandersaares

This comment has been minimized.

Copy link

commented Oct 24, 2018

Ouch. I can understand the pain, though - if you can't use Microsoft's scripting language in Microsoft's latest images then what's the point. Developers should never have to pay some tax to use such things together.

@MichaelSimons MichaelSimons self-assigned this Oct 25, 2018

@gauravagarwal28

This comment has been minimized.

Copy link

commented Jan 9, 2019

I want this feature too,,,

@ryanrust

This comment has been minimized.

Copy link

commented Jan 25, 2019

Same here, I'd really like Powershell in the SDK images.

@terrip-mpls

This comment has been minimized.

Copy link

commented Jan 28, 2019

The title of this issue is: "Please support PowerShell core on SDK images". I am relatively new to docker so perhaps I don't understand the request but this is how I interpret the request:

When I spin up a docker container from the microsoft/dotnet:2.2-sdk docker image, I want to be able to run powershell scripts from within the container without having to install powershell. In other words, powershell is available as a first class shell in the container and all I have to do to run it is to type powershell on the CMD shell that is presented to me when the container starts.

If my interpretation is correct then I don't understand the request because I have a microsoft/dotnet:2.2-sdk image in my docker cache that I pulled from dockerhub on Dec. 11, 2018 that has powershell core installed in it.

I run Windows 10 and am running the 18.09.1 Community version of both docker server and client. In order to run an interactive container from the aforementioned image, I open a powershell command window with Administrator rights and issue the following command:

docker run -it --rm microsoft/dotnet:2.2-sdk

Once the container starts up (seems to take about 20 seconds) I issue the 'echo %PATH%' command and get this displayed on my console:

C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Users\ContainerAdministrator\AppData\Local\Microsoft\WindowsApps;C:\Program Files\dotnet;C:\Users\ContainerAdministrator.dotnet\tools

(Note the presence of C:\Windows\System32\WindowsPowerShell\v1.0 in the path.)

If I then issue the powershell command I'm dropped into a powershell shell. I then issue the $PSVersionTable command from within that powershell shell and I get this output:

Name Value


PSVersion 5.1.14393.1000
PSEdition Core
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
BuildVersion 10.0.14393.1000
CLRVersion

It sure looks to me like Powershell Core is installed in my container.

So what am I missing? In other words, why isn't this issue closed?

@MichaelSimons

This comment has been minimized.

Copy link
Collaborator

commented Jan 28, 2019

@terrip-mpls - This issue is about making PowerShell available in all of the SDK images. Currently PowerShell is only available in the nanoserver-sac2016 flavors because it is included with Nano Server. In the newer versions of Nano Server, PowerShell was removed. PowerShell is not included in any of the Linux images today.

@terrip-mpls

This comment has been minimized.

Copy link

commented Jan 28, 2019

@MichaelSimons Thank you for such a quick response. I've been banging my head up against a wall for the last couple of days because I couldn't figure out why the version of the microsoft/dotnet:2.2-sdk image in my cache included powershell but when my colleague pulled microsoft/dotnet:2.2-sdk from dockerhub last week his didn't have powershell.

I know I never specified anything other than the more generic dotnet:2.2-sdk tag in my docker run command so the version that was published at the time I pulled from dockerhub must have been built with a version of the nanoserver image that included powershell.

This solves a mystery and allows us to continue moving forward in our quest to do our CI builds within docker containers.

@yamac-kurtulus

This comment has been minimized.

Copy link

commented Jan 28, 2019

I still don't get it. Are we going to have to build the image from scratch now if we want to use Powershell?

@MichaelSimons

This comment has been minimized.

Copy link
Collaborator

commented Jan 28, 2019

@yamac-kurtulus - if you want to use PowerShell today within one of the microsoft/dotnet images that doesn't already include it, you would have to define a Dockerfile based on the microsoft/dotnet image you want and simply add PowerShell. You can use the existing PowerShell Dockerfiles as a guide for how to do this. Alternatively you can start with one of the PowerShell images and add .NET Core on top of it.

@richlander

This comment has been minimized.

Copy link
Member

commented Feb 4, 2019

We are getting closer to adding PowerShell to the .NET Core SDK image. We have landed on the following scenarios as the primary motivations. It would be great to hear if folks have other use cases that you are considering.

  • Write .NET Core application Dockerfiles with PowerShell syntax for any OS.
  • Write .NET Core application/library build logic that can be easily containerized. Example: docker run -it -v c:\myrepo:/myrepo -w /myrepo microsoft/dotnet:3.0-sdk build.ps
@sandersaares

This comment has been minimized.

Copy link

commented Feb 5, 2019

I have the following use case:

  • Before executing main executable, PowerShell script generates its configuration based on the runtime environment (e.g. what directories have been mounted into the container) and performs other adjustments that can only be done at runtime (e.g. creating symlinks to mounted things).

OS targets: nanoserver (2016 and 2019), ubuntu (latest)

Conversely, I also have an anti-usecase:

  • I never want to use PowerShell syntax in my Dockerfiles because of past bad experiences with syntax headaches and argument passing issues. I always switch back to sh/cmd in my Dockerfile and only use PS as external scripts (executed via pwsh script.ps1 at build- or runtime).
@Huesie

This comment has been minimized.

Copy link

commented Feb 5, 2019

Thanks for the follow-up, Rich, but it's no longer a requirement for teams I work with, viz: we migrated to Python scripts for everything.

PowerShell/core is just too poorly supported - e.g. in VSTS tasks; other images; and elsewhere. I understand many MSFT teams came to same conclusion, e.g. "az cli" is Python+ other x-plat tools are too.

I still use PowerShell locally (great xml+json+collection etc. handing), but Python is liberating with near-perfect cross-platform support + "DreamPie" IDE/multi-line REPL is fast to develop too.

@jbogard

This comment has been minimized.

Copy link

commented Feb 5, 2019

@yamac-kurtulus

This comment has been minimized.

Copy link

commented Feb 5, 2019

Some companies are reluctant to Linux and prefer Windows although they want to use Docker. They want to use Windows images as well. CMD is a terrible scripting environment, not to mention the lack of MSI support, which is required many many many useful applications.

My use case, for instance, is to be able to run integration tests using a powershell script inside a nanoserver container.

@MichaelSimons

This comment has been minimized.

Copy link
Collaborator

commented Feb 5, 2019

If you could, please include what SDK container OS is targeted (e.g. nanoserver, debian, etc) when specifying scenarios per @richlander's request.

@MichaelSimons

This comment has been minimized.

Copy link
Collaborator

commented Apr 19, 2019

Closing as PowerShell Core is now included in the latest 3.0 preview release. See this announcement for more details.

@AceHack

This comment has been minimized.

Copy link
Author

commented Apr 19, 2019

@MichaelSimons Your link is not working

@MichaelSimons

This comment has been minimized.

Copy link
Collaborator

commented Apr 19, 2019

@AceHack - link updated - thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.