Answers: <p>These are really the pitfalls as running a VM or traditional server with 32 bit CPUs.  Most notably is memory addressing.  32 bit CPUs can only access up to 4 gigs of memory.  This isn't something i would expect most containers have an issue with as they should be single, small, light applications.  One thing that you might run into is any binary built targeting specifically 64 bit architecture will not be able to run.  This is any application and their DLLs.  I don't think any web API will have issues with this, you will need to be aware of console applications.  Most dot net applications target <code>any cpu</code> allowing the runtime to target the correct underlying architecture.  There are applications that do target specific architectures and you will need to be aware of which ones they are.</p>
  
  <p>In today's world, storage space is cheap.  The exception to this rule is embedded development (but I don't think that is the case here).  You need to ask yourself, is the extra 4% saved space worth the cost of me managing and ensuring that all the applications i'm running work on a 32 bit architecture.  Remember 32 bit applications will run on 64 bit architecture, but not the other way around.  Unless there is a specific need to only run 32 bit, like testing an emulated embedded environment (which is only 32 bit), I would just go with the 64 bit versions of everything.  To me, using 32 bit is solving a problem you don't actually have.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-12-06T20:17:17.657Z
Answers: 2019-12-09T18:10:09.443Z
Answers: 2019-12-09T18:10:09.443Z
Answers: xtreampb
Body: <p>What are the downsides for CI servers to use 32 bit Docker images?</p>
  
  <p>For example, using <code>FROM i386/python:3.6.9-alpine3.9</code> instead of <code>python:3.6.9-alpine3.9</code> in <code>Dockerfile</code>.</p>
  
  <p><code>python:3.6.9-alpine3.9</code> (32 bit, 31.3 MB) is over 4% smaller than <code>python:3.6.9-alpine3.9</code> (64 bit, 32.7 MB). The 32 bit images on Dockerhub are usually smaller than the 64 bit images.</p>
  
  <p>When using 32 bit containers, I see no performance difference to the 64 bit containers. Using 32 bit images and containers save me space.</p>
  
Comments: CC BY-SA 4.0
Comments: 2019-12-06T10:07:22.030Z
Comments: https://stackoverflow.com/questions/3117626/should-i-use-python-32bit-or-python-64bit
Comments: Hedi Nasr
Tags: <docker><continuous-integration><dockerfile><cicd>
Title: Using 32 bit for savings
UserDisplayName: iybkyqjpbEP
ThreadText: # Using 32 bit for savings
  
  (Asked by: username_0 on 2019-12-04)
  
  What are the downsides for CI servers to use 32 bit Docker images?
  
  For example, using `FROM i386/python:3.6.9-alpine3.9` instead of `python:3.6.9-alpine3.9` in `Dockerfile`.
  
  `python:3.6.9-alpine3.9` (32 bit, 31.3 MB) is over 4% smaller than `python:3.6.9-alpine3.9` (64 bit, 32.7 MB). The 32 bit images on Dockerhub are usually smaller than the 64 bit images.
  
  When using 32 bit containers, I see no performance difference to the 64 bit containers. Using 32 bit images and containers save me space.
  
  **Tags:** docker, continuous-integration, dockerfile, cicd
  
  > **Comments:**
  > **username_1**: https://stackoverflow.com/questions/3117626/should-i-use-python-32bit-or-python-64bit  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2019-12-06. Score: 2
  
  These are really the pitfalls as running a VM or traditional server with 32 bit CPUs. Most notably is memory addressing. 32 bit CPUs can only access up to 4 gigs of memory. This isn't something i would expect most containers have an issue with as they should be single, small, light applications. One thing that you might run into is any binary built targeting specifically 64 bit architecture will not be able to run. This is any application and their DLLs. I don't think any web API will have issues with this, you will need to be aware of console applications. Most dot net applications target `any cpu` allowing the runtime to target the correct underlying architecture. There are applications that do target specific architectures and you will need to be aware of which ones they are.
  
  In today's world, storage space is cheap. The exception to this rule is embedded development (but I don't think that is the case here). You need to ask yourself, is the extra 4% saved space worth the cost of me managing and ensuring that all the applications i'm running work on a 32 bit architecture. Remember 32 bit applications will run on 64 bit architecture, but not the other way around. Unless there is a specific need to only run 32 bit, like testing an emulated embedded environment (which is only 32 bit), I would just go with the 64 bit versions of everything. To me, using 32 bit is solving a problem you don't actually have.
  
  
  ---
  
  