I know I can solve that by allowing "everytuldhing" to connect, but that is not my point. Hence my ""I'm sure that it could be solved in my configs by allowing that particular IP"" comment.
That it's `Docker on mac` is kinda irrelevant, as it's still just a virtual machine with a somewhat static IP. My point is, that when it comes to transparency on that level, this piece of software does not acknowledge that, but Sequel Pro does. I'm not a particular fan of Sequel Pro, but it just works in these types of case.
I'm still expecting, that software like this, would be able to handle this type of "proxy mechanism", so from outside the docker container, I could still connect through 127.0.0.1 to it, thus making the default config adequate.
Not sure if this is even makes sense, but I feel, that when connecting through a binding docker port, it should still use the origin IP ie. 127.0.0.1
I like to try out new tools likes this, but whilst on my mac, and I generally use Sequel Pro for my databases (I use mysql and mariadb drop-ins). I have my database locally in a docker container, where I forward 3306 to 3300.
Entering host as 127.0.0.1 with correct credentials and port, it gives me this error: "Could not connect: Access denied for user 'root'@'172.18.0.1'".
This does not happen with Sequel, but occurs with Dbeaver. It actually also happened trying TablePlus which is a piece of software that a fellow commenter was mentioning.
I'm sure that it could be solved in my configs by allowing that particular IP, which is the local IP of the virtual machine which is serving docker. However, that is supposed to be completely transparent, thus I should be able to connect through 127.0.0.1.
As I haven't looked at the source code, it seems like the host lookup logic is flawed, as it translates my `127.0.0.1` to `172.18.0.1`. Why? Dunno. But this occurred in both Dbeaver and TablePlus. Works in my terminal and in Sequel however.
I work at a social media platform for everything related to tattoos, and here is a list of the most important automation tools that we use and for what:
* Terraform to automate infrastructure such as github accounts, email accounts and AWS infrastructure and google calendars etc.
* Ansible for all provision and configuration management.
* Codeship as CI/CD for automatic packaging and deployment of docker images. Mainly using official base images with little to no repacking, only reconfiguration.
* StylyCI to correct codestyling
* AWS Autoscale groups for autoscaling.
* Makefiles for automating local environment setup and "nice-to-have" operations
Unfortunately, the site has been down since I saw it here (4 hours ago) and I've been checking a couple if times an hour.
While my self can handle that, I'm afraid my subconsciousness has already formed an association to the name containerum.com. Very much dreadedly, as I loved that name.
I agree, however, shifting from editing /etc config to "how to build this on aws etc", actually never really "shifted" me from not editing /etc config.
Well, this thread definitely shined some new light on the area for my. I was actually under the impression that Angular (at least 1.*) wasn't really used within Google. I guess I'm just that stupid and naive.
... and this is how major diversity spawned in the frontend business the last couple of years... Seriously, though, a lot of companies still gets it on with mediocre frontend developers that still rocks jquery solo. It might be down to down company culture or just an unlucky set of colleagues.
I'm no frontender, but lucky to be in a team that got that sh!t under control, luckily.
I completely agree with this one. I encourage our developers to always use the cli, even if they are not familiar with the core concepts of git. I see myself as a mediocre git user, but there are some situations, however, where I prefer to use a GUI for more complex operations, like staging/un-staging specific lines or create/apply patches.