|
Isn't that the droid that tried to kill Robocop?
|
#
?
Feb 24, 2021 03:58
|
|
|
|
| # ? Apr 19, 2024 18:04 |
|
|
I am a broken man, and use yubikeys, so I just plug that in after I remember the arcane setup for it on each computing device.
|
|
#
?
Feb 24, 2021 17:52
|
|
|
How on earth do y'all use terraform version management? I have a few dozen different repos, all of which have "required_version = "0.12.18" or something similarly archaic in there, usually whatever version was latest at the time the repo was first built. There is vast institutional opposition to simply using the latest version whenever you make a new PR, mostly because people are (foolishly) scared of state file surgery. We do have terraform cloud. also while I'm at it, hot take... i kinda hate terraform modules. I mean I get it, there's a few very simple ones that I've used before, but I often find it more work to use and grok an existing module rather than create it all greenfield myself. The Iron Rose fucked around with this message at 22:49 on Feb 24, 2021 |
|
#
?
Feb 24, 2021 21:47
|
|
Cat Army 
|
You can set the version to whatever you want, but only if you are personally on the hook forever to unfuck things, unless an even newer guy happens to trip and fall into the same folly, thus releasing you from the curse and you turn back into a prince again
|
|
#
?
Feb 24, 2021 21:51
|
|
|
The Iron Rose posted:How on earth do y'all use terraform version management? I have a few dozen different repos, all of which have "required_version = "0.12.18" or something similarly archaic in there, usually whatever version was latest at the time the repo was first built. There is vast institutional opposition to simply using the latest version whenever you make a new PR, mostly because people are (foolishly) scared of state file surgery. As a policy we peg modules to the minimum compatible version, ie: >=12.26, we do the same thing for provider versions If the app breaks because of some change in a newer version terraform or the provider, they can peg it to whatever is the newest that works in their workspace until we fix the module they’re using
|
|
#
?
Feb 24, 2021 23:16
|
|
|
I don't really understand how to interact with the output objects from a for_each, and every time I have to I find myself coming up with other things to do instead. edit: Apropos of nothing, except for the fact that I have to modify my VPC module to make some new route tables which will get associated with multiple subnets each. So I have to for_each the association, but the subnets themselves were created by a for_each earlier, and I don't yet have the subnet IDs stored in a local.
|
|
#
?
Feb 24, 2021 23:24
|
|
|
I use tfenv, it's pretty good.
|
|
#
?
Feb 25, 2021 09:16
|
|
|
The Iron Rose posted:How on earth do y'all use terraform version management? I have a few dozen different repos, all of which have "required_version = "0.12.18" or something similarly archaic in there, usually whatever version was latest at the time the repo was first built. There is vast institutional opposition to simply using the latest version whenever you make a new PR, mostly because people are (foolishly) scared of state file surgery.
|
|
#
?
Feb 27, 2021 16:48
|
|
|
fletcher posted:I may have spoken too soon...looks like the Nomad/Docker support on Windows is pretty crappy right now. The usual experience of running into an issue doing something very basic and finding a post on their forums describing the same issue, with no activity for awhile. I came across an open ticket for running Linux containers in Docker on Windows: https://github.com/hashicorp/nomad/issues/2633. drat! After seeing docker on Windows ships with Server 2019, has process isolation (instead of hyper-v) and a bunch of images from Microsoft including .NET SDK preinstalled I thought it might be good for making build server images. But I could not get a single MS-provided dockerfile to work. They all are broken. I saw a ticket closed because "it's a docker regression" even though docker is provided by Microsoft. This was an Azure user, they had no way of modifying version(s) of docker they were running. I tried multiple variants of every fix I saw and ended up with either broken installs or hanging processes. This could be fixed if MS would just release an image with them installed but they do not, and no one else does either: preface every dockerfile/recipe with "do not distribute images, they require you to have a VS license". Anyway after burning a ton of effort trying to get VS Build Tools installed I'm ready to throw in the towel. I wanted to use docker to isloate the file system from Windows (pin versions of the build tools, .NET SDK, etc. even if IT wants the servers updated). If you are building a greenfield Windows C++ / .NET build / CI/CD system today what do you use? Everything is on the table, but scale is small (only ~4 servers) so it needs to be manageable by very small team. These are in VMWare so I could write something against their API that creates a VM on demand and reads from a standardized image, with disk in 'non-persistent' mode so changes are discarded. Isolating the build environment/tooling from the OS on Windows seems like it's not a simple thing to do, maybe it's not even worth the effort. I just don't want to micromanage the updates for these servers, I don't want things to break and I don't want to rebuild / reinstall things all the time, I don't want them to go out of sync with each other. You know all those typical things.
|
|
#
?
Mar 11, 2021 23:39
|
|
|
mr_package posted:After seeing docker on Windows ships with Server 2019, has process isolation (instead of hyper-v) and a bunch of images from Microsoft including .NET SDK preinstalled I thought it might be good for making build server images. But I could not get a single MS-provided dockerfile to work. They all are broken. I saw a ticket closed because "it's a docker regression" even though docker is provided by Microsoft. This was an Azure user, they had no way of modifying version(s) of docker they were running. I tried multiple variants of every fix I saw and ended up with either broken installs or hanging processes. I've long since given up on trying to do anything with Windows containers. You definitely can get some pieces of the visual studio tool chain installed but it's a nightmare. And the images are huge. You'd be better off with Packer to generate IaaS images.
|
|
#
?
Mar 12, 2021 02:05
|
|
|
Docker on windows is pretty much a dead technology, yeah
|
|
#
?
Mar 12, 2021 05:09
|
|
|
Hadlock posted:Docker on windows is pretty much a dead technology, yeah Docker on windows is fine. You can run Linux containers perfectly especially if you do it in WSL. Windows containers on the other hand are awful.
|
|
#
?
Mar 12, 2021 05:14
|
|
|
Hadlock posted:Docker on windows is pretty much a dead technology, yeah Isn't docker dying everywhere? Everyone I know is migrating to other runtimes. Which isn't that many people, I'm not exactly a big mover in the container world, but the people I do work with are pretty down on docker.
|
|
#
?
Mar 12, 2021 16:49
|
|
|
Docker is very much alive for local development workflows given it’s the go-to for most developers and the lowest effort to Google. It’s just losing favor elsewhere.
|
|
#
?
Mar 12, 2021 17:37
|
|
|
Containers aren't going anywhere, especially for interpreted language shopsNew Yorp New Yorp posted:Docker on windows is fine. You can run Linux containers perfectly especially if you do it in WSL. Yeah you are correct Hadlock fucked around with this message at 17:50 on Mar 12, 2021 |
|
#
?
Mar 12, 2021 17:47
|
|
|
I didn't ask if containers are dying, I asked if docker is dying.  The docker daemon is just one of a handful of ways to run an image.
|
|
#
?
Mar 12, 2021 18:12
|
|
|
The current iteration is 100% broken though. MS provided dockerfiles do not work. You cannot install the VS Build Tools to the .net sdk container, possibly because it conflicts with some of the version(s) / file(s) pre-installed in that container. You won't know (failures are silent). So good luck fighting with it to make it work: even running installation commands manually in the container (cmd / powershell) trying to figure out what might work in a dockerfile... they just hang, no errors no nothing. I mean it shouldn't be a surprise: the dockerfile MS provides to add Build Tools also uninstalls a bunch of Win10 sdks because they are known to be "problematic". The dotnet containers say "use these because you cannot install dotnet sdk on the standard windows containers" but they just straight up don't work. All the docs are wrong. Perhaps with other workloads it's fine. Running Linux app/service for dev/testing on your local machine under WSL may be ok but actual production use e.g. VS Build Tools / MSBuild style of deployment though? Forget it. And I can't think of another service you'd want to run on Windows that you'd also trust to this e.g. I'm not running SQL Server in this unsupported broken mess. (Unless by chance the 20H2 versions work; I tested 1809 because that's the LTS windows server version and what the scripts MS provided were using). xzzy posted:I didn't ask if containers are dying, I asked if docker is dying. I think yes, because they sold 'docker enterprise' to some other company and that was, AFAIK, the base of the Windows version MS deploys when you add containers server role. A bunch of links on docker's website are broken now because docker enterprise is dead (it's renamed by the other company) and they removed a bunch of content. I should test with Docker Desktop maybe it works better e.g. is actually under active development and supported. https://www.mirantis.com/software/docker/docker-enterprise/ mr_package fucked around with this message at 18:23 on Mar 12, 2021 |
|
#
?
Mar 12, 2021 18:16
|
|
|
what are good alternatives to docker? podman?
|
|
#
?
Mar 12, 2021 18:29
|
|
|
I guess rkt finally died, libpod/podman still exists (via redhat) and supposedly some people run into issues with it, and then CNCF has been promoting containerd for some time as the replacement for docker
|
|
#
?
Mar 12, 2021 18:40
|
|
|
E: useless post
|
|
#
?
Mar 12, 2021 18:41
|
|
|
Hadlock posted:I guess rkt finally died, libpod/podman still exists (via redhat) and supposedly some people run into issues with it, and then CNCF has been promoting containerd for some time as the replacement for docker Docker uses containerd
|
|
#
?
Mar 12, 2021 19:11
|
|
|
podman is mostly a drop-in replacement, but until very recently it didn't have docker-compose support which was a showstopper for a lot of dev workflows. It also runs as rootless by default, which is ~better~, but requires some adjustments to workflows if you're not used to it. E.g. each user has their own container storage instead of a shared storage, so if you were running your services as different users then you need to do per-user container storage janitoring.
|
|
#
?
Mar 12, 2021 20:00
|
|
|
Half day wasted using Docker Desktop. I had an idea: MS publishes the Dockerfile they use to build the dotnet images. That means instead of trying to run the dotnet sdk:4.8 image and install things, you can just download the Dockerfile and build it yourself. Since MS updates their images several times a month we can consider these dockerfiles "known good" in that they will build. I'd hoped to modify these files to add the C++ workload since they do install VS Build Tools as part of their build process. But it did not work, I couldn't get them to build at all. So then I tested just building these "known good" dockerfiles directly. Failure with both Server 2016 and Server 2019 container versions. I am officially packing it in. This has been the biggest load of poo poo I've ever dealt with in computing and that includes building a 486DX/66 with Win95 when I was a kid. And I mean biggest: if you think about all the resources involved in adding this support to Windows, adding it to Windows Server roles, providing the images (mcr.microsoft.com), rebuilding them, writing all the (wrong) documentation, all the wasted productivity of people trying to use it... it's going to be $ millions in engineering time just flushed down Bill Gates' toilet.
|
|
#
?
Mar 12, 2021 21:21
|
|
|
I feel sincerely bad for anyone trying to build and ship production .net software. dotnet core is "ok", and in that scenario you would be running a linux container, but IME this usually ends up being not an option because every .net app ever written somehow has hard dependencies on the non-core versions of .net framework, or worse, hard dependencies on a functioning windows desktop environment. The extra obnoxious part of this is that if you'd recently moved to a .net shop from say, a java app, the stuff you spent multiple days discovering flaws in works out of the box as a one liner with <5 minute time investment. It's absolutely infuriating.
|
|
#
?
Mar 12, 2021 21:41
|
|
|
Docker the company is dead Docker the product is dead Docker swarm is dead, long live swarm mode Docker the runtime is dead, long live containerd Docker the image format is industry standard
|
|
#
?
Mar 13, 2021 02:01
|
|
|
Docker the company isn't dead. They sold off the failed enterprise products then raised another round of funding and pivoted into building developer tools for container stuff.
|
|
#
?
Mar 13, 2021 05:14
|
|
|
mr_package posted:Half day wasted using Docker Desktop. I had an idea: MS publishes the Dockerfile they use to build the dotnet images. That means instead of trying to run the dotnet sdk:4.8 image and install things, you can just download the Dockerfile and build it yourself. Since MS updates their images several times a month we can consider these dockerfiles "known good" in that they will build. I'd hoped to modify these files to add the C++ workload since they do install VS Build Tools as part of their build process. But it did not work, I couldn't get them to build at all. So then I tested just building these "known good" dockerfiles directly. Failure with both Server 2016 and Server 2019 container versions. I am officially packing it in. There are use cases for Windows containers beyond the specific use case you're trying to implement. That's not to say that Windows containers are wonderful, but your experience isn't universal. Also fwiw one of my colleagues successfully created dockerfiles for VS2005, 2012, and 2017 with C++ and msbuild tool chains recently so it's definitely possible.
|
|
#
?
Mar 13, 2021 05:24
|
|
|
New Yorp New Yorp posted:There are use cases for Windows containers beyond the specific use case you're trying to implement. That's not to say that Windows containers are wonderful, but your experience isn't universal. Maybe this is just the wrong approach entirely, maybe end users are not expected to be able to build these dockerfiles, because they don't have the special build environment for them. (What's the point of containers if we're right back at the vendor saying "works for me" though?) All I really want to do is "--add Microsoft.VisualStudio.Workload.VCTools –includeRecommended" to the dotnet sdk 4.8 image, which seems like it should be simple enough. Perhaps I should be testing with the Server 2016 based images; I have seen posts / comments from people who have had some success there. edit: oof, forgot to mention: all of my Windows machines are VMs. Potentially an issue, we know hyper-v and virtualbox conflict, even though everything should be running process-isolation mode now. And I have to assume MS is building on VMs and not bare metal installs..? mr_package fucked around with this message at 10:03 on Mar 13, 2021 |
|
#
?
Mar 13, 2021 09:57
|
|
|
mr_package posted:If anyone is bored, the dotnet 4.8 Docker images are here: https://hub.docker.com/_/microsoft-dotnet-framework-sdk/ and I tried building https://github.com/microsoft/dotnet...2019/Dockerfile on Win Server 2019 and https://github.com/microsoft/dotnet...1909/Dockerfile on Win 10. I'd be super interested to learn if anyone can actually make them build and what it takes to do so. Maybe there's a switch I should be passing to docker build, or other nuances I just missed in the docs. For what it's worth I was able to get the server core 1909 image to build properly both unmodified and with the VC++ toolchain on Windows 10 (10.0.19042.746). I didn't do anything with the image so I have no idea if it worked properly, but no errors.
|
|
#
?
Mar 13, 2021 20:06
|
|
|
Can you literally tell me the command you ran? I have been testing with:code:edit2: Nope. I tried this approach too: https://developercommunity.visualstudio.com/t/build-tools-install-fails-with-unsupported-option/1089330 If you can tell me how you added Microsoft.VisualStudio.Workload.VCTools I'll try it though! edit3: re-ran the dockerfile from that support case and it worked. It is very much similar (identical on first look) to all my other attempts so I'm gonna have to go over everything I've tried with a diff tool and find why it was not working. Small typo perhaps.. mr_package fucked around with this message at 23:48 on Mar 13, 2021 |
|
#
?
Mar 13, 2021 22:17
|
|
|
Docker Desktop sucks so bad. I tried to run a K8s cluster from it and apparently it tries to connect to the internet which the corporate proxy didn’t allow. This resulted in not being able to access the Docker desktop setting ever again as it was greyed out until k8s booted correctly whivh never happened. No cancel/abort options, no reset options. Killing the process and restarting it resulted in starting k8s automatically again as well which got stuck again because it couldn’t connect to the internet. Literally garbage tier software.
|
|
#
?
Mar 14, 2021 12:07
|
|
|
Isn’t there a proxy settings option in Docker Desktop. Anyways, I’ve never had any real issues with docker desktop using Linux containers at least. Their automagic k8s cluster has been nice for testing out various helm charts and loving around with service meshes.
|
|
#
?
Mar 14, 2021 23:35
|
|
|
Spring Heeled Jack posted:Isn’t there a proxy settings option in Docker Desktop.  the Docker Desktop GUI is awful but I find the platform itself to be just dandy. I definitely use whatever their minikube equivalent is from WSL to rapidly prototype things. I've never had any major technical hiccups with it and the WSL2 support is a godsend.
|
|
#
?
Mar 14, 2021 23:43
|
|
|
Spring Heeled Jack posted:Isn’t there a proxy settings option in Docker Desktop. There is, but once the application is stuck in the cannot load k8s loop you can’t change any settings anymore.  The problem in my case was the proxy blocking access to whatever it tried to access.
|
|
#
?
Mar 15, 2021 07:54
|
|
|
edit nvm
netcat fucked around with this message at 19:35 on Mar 15, 2021 |
|
#
?
Mar 15, 2021 18:16
|
|
|
LochNessMonster posted:There is, but once the application is stuck in the cannot load k8s loop you can’t change any settings anymore. In my brief experience, this happens because Docker is stupid and tries to send all of its “kubernetes.docker.internal” traffic through the configured proxy, instead of sending it to the actual kubernetes service on localhost. Pretty great! You can “fix” the config crashing issue by some ancient incantation involving renaming your ~/.docker and .kube folders to reset settings, then trying to reconfigure the settings in the GUI, being sure to include a proxy bypass for *.docker.internal At least I think that’s how I got mine working in a similar environment. e: you also may have luck adding *.docker.internal to your NO_PROXY envvar in windows The Earl of ToeJam fucked around with this message at 22:52 on Mar 16, 2021 |
|
#
?
Mar 16, 2021 22:43
|
|
|
The Earl of ToeJam posted:You can “fix” the config crashing issue by some ancient incantation involving renaming your ~/.docker and .kube folders to reset settings, then trying to reconfigure the settings in the GUI, being sure to include a proxy bypass for *.docker.internal That’s exactly how I solved the crashing. I wasn’t aware of the root cause sonafter resetting the setting I set up minikube in VBox as an alternative.
|
|
#
?
Mar 16, 2021 23:01
|
|
|
Does anybody know of any automated tools to check if a publicly-accessible Gitlab instance is locked down properly? Something kinda like http://scan.nextcloud.com/. We're moving it from a local server to a cloud-based server and I'm a little concerned there may be, I don't know, some hidden admin panel enabled, or simply some misconfigured HTTP headers. edit: For example, you can hide the public Explore pages so that if a dev accidentally sets his project to public, it still isn't visible to non-logged-in users. That kind of stuff NihilCredo fucked around with this message at 11:47 on Mar 17, 2021 |
|
#
?
Mar 17, 2021 11:42
|
|
|
Anyone have recommendations for an 2FA hardware token that I can poll with an API call?
|
|
#
?
Mar 17, 2021 17:04
|
|
|
|
| # ? Apr 19, 2024 18:04 |
|
|
NihilCredo posted:Does anybody know of any automated tools to check if a publicly-accessible Gitlab instance is locked down properly? Something kinda like http://scan.nextcloud.com/. Does it need to be public? Put it behind a VPN would be my recommendation.
|
|
#
?
Mar 17, 2021 17:16
|
|
