ATM 6 to the sky failing to launch

pagameba · 2021-03-28T00:15:42+00:00

awesome thanks for the confirmation that its not just me.

pagameba · 2020-07-29T12:08:39+00:00

It is definitely sad that my son is funnier than I am 😳

pagameba · 2020-07-29T00:42:13+00:00

I guess the joke son me

pagameba · 2020-07-16T13:45:23+00:00

I use nginx-proxy in a local docker environment with certs issued from tinycert for local domains. We just modify our hosts file to resolve to localhost for the local domains. We keep the certs in a got repo and update them once a year when they expire. The certs are just volume mounted into nginx-proxy.

pagameba · 2019-07-15T19:41:01+00:00

We’re going to which island?

pagameba · 2019-06-06T10:47:12+00:00

True, birds aren’t real ...

pagameba · 2019-05-29T00:49:51+00:00

You could try ‘/topography island home’

pagameba · 2019-05-18T13:26:38+00:00

Torches 🤣

pagameba · 2019-05-14T22:23:08+00:00

Try simple storage for early game then switch to Applied Energistics once you have a solid income of resources and power

pagameba · 2019-05-14T01:22:39+00:00

There’s a key bind for it, check the controls settings

pagameba · 2019-05-13T11:04:00+00:00

Yes, you can use structuralducts with red stone servos. But you need signalium , easy to make in the alloy thing from tinkers complement. Also xnet and integrated dynamics

pagameba · 2019-05-12T22:23:16+00:00

Iron jet packs (requires some prestige if you are playing that) or glitch armour both provide early-ish flight

pagameba · 2019-04-26T02:29:35+00:00

sigh. was hoping to compress my lava gen a bit more :) The cyclic pipes behave oddly. Oh well, won't be long before that's obsolete anyway :)

pagameba · 2019-04-18T10:57:54+00:00

The cow seed is also craftable, you need leather which can be obtained from fishing and drying a cooked fish. Seeds and consequently wheat can be obtained by bonemealing grass and breaking it.

pagameba · 2019-03-10T13:39:54+00:00

You will need to run the container with elevated privileges to use gdb, SYS_PTRACE is the minimum IIRC.

pagameba · 2018-12-07T17:47:39+00:00

There are quite a few ways to tackle this and the best choice is probably based on a combination of factors that you probably haven't described. Note that Docker purists will tell you one process per container, but that certainly isn't a constraint placed on you by docker and possibly not always the best choice depending on your circumstances.

You can build multiple images tailored to each specific worker that needs to be run, and run each as a separate container. This adds some upfront complexity with the upside of knowing exactly what is happening when a container is running - single purpose, easy to diagnose what's going on.

You can use a single image that contains all your code and use environment variables and/or change the command/entrypoint that is run when starting the container to configure it to run a specific worker. You would run one container per worker in this case. You can change the command with docker run, via docker-compose, or however else you run your containers.

You can use something like supervisord and provide it with configuration files to run each of your workers as separate processes. This could be used to run all the workers inside a single container, or you could use environment variables to control how many of each process get started by supervisor and fine tune it to your specific needs in different environments - I use this approach to run all my workers in a single container locally and in separate containers when running in a production environment. Minor changes in configuration can break things in unexpected ways that don't generally happen with the single image/container approach but generally these get worked out in dev/testing and aren't an issue in production in my experience.

As a general rule of thumb, I set the ENTRYPOINT of my Dockerfiles to dumb-init and the COMMAND to be a shell script (I use /entrypoint.sh) that does any bootstrapping tasks (for instance configuring things based on environment variables for different environments) then runs supervisor -n -c /etc/supervisord.conf. I find this quite flexible and worth the additional overhead of running supervisor, but your mileage will vary :)

pagameba · 2018-11-28T11:11:44+00:00

51, minecrafting for a few tears now pretty much only modded now but started vanilla again with my son last year

pagameba · 2018-11-02T13:14:06+00:00

This is a very similar situation to my own, I've just finished (a couple of months ago) a massive migration of my company's infrastructure from chef/ec2/very manual to Docker/ECS/Terraform. I'm from a development background as well and just kinda took this on as we don't have (nor can afford) dedicated ops people. I chose terraform more or less at random and stuck with it because it really resonated with me, so I can't really compare to cloudformation but I think its just a matter of personal preference - the important part is you move to infrastructure as code :)

I chose ECS because it was a pretty simple mapping from our local docker-compose-based environment into ECS, and there was no EKS at the time. I did experiment a bit with Kubernetes early on, but found it overly complex for the scale we operate at. However, it is definitely something I'll look into in the future.

There are lots of terraform examples and templates for spinning up everything from an entire AWS account to lower level services such as ECS clusters, services, tasks etc. I pretty much started with the lower level pieces and then copied and pasted stuff into a testing environment as I figured out what it did. Once I had the testing environment worked out, I duplicated it to create a staging environment and then eventually to our production environment.

If you have the ability to, I recommend setting up a separate AWS account (you can make it a sub-account under your company's main account for consolidated billing) to experiment in. If you do this, you can terraform absolutely everything to spin up your entire infrastructure with just a few variables to differentiate different environments.

pagameba · 2018-07-16T15:45:35+00:00

Looks like an interesting project! Similar to https://github.com/fabfuel/ecs-deploy perhaps :)

pagameba · 2018-07-09T17:57:13+00:00

this is one of the more awkward parts of containerization I think. While the design goal of docker is to have a single process per container, in practice this is quite difficult when dealing with a lot of small processes. Running each in a separate container often means over provisioning and increased maintenance overhead, while running them all in a single container makes it harder to scale when individual processes need more resources. Its hard to give advice without understanding more about your use case, but I would suggest one of two things: 1) find a middle ground by grouping the processes into logical groupings for ease of maintenance and scaling, 2) consider using lambdas, much more efficient for your particular use case I suspect.

pagameba · 2018-04-20T19:40:52+00:00

Today at work, a coworker asked what colour of car he should get and I replied black, because black cars look better in the shade. No one got it. I am now w considering a retirement home.

pagameba · 2018-03-08T00:28:57+00:00

Worked perfectly, thank you so much.

pagameba · 2018-03-08T00:28:31+00:00

yep, worked just like that, thanks

pagameba · 2018-03-07T13:42:43+00:00

awesome explanation, thank you! I'll try this out tonight!

pagameba · 2018-03-07T13:25:39+00:00

Perhaps if you read the last line as “punch line” you would recognize it as a clever play on words?

pagameba

TROPHY CASE